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ABSTRACT 



Method, system, and apparatus are described for automati- 
cally receiving, at an intermediate processing location, data 
from a wide variety of remote sources, identifying the 
format of the data, translating the data to a common file 
format, sending the data to a recipient in an intermediate 
format, then translating the data to the specific format 
needed by the particular recipient The system operates 
automatically with little human intervention. A unique sys- 
tem for automatically selecting and implementing specific 
translation modules is also described. Error checking fea- 
tures ensure that the transferred data matches the original 
data although the format is altered, and documentary 
receipts are sent to each section of the system that sends 
data, and logical, statistical and mathematical operations 
may be performed on the data The system utilizes internal 
databases which allows it to know what format data will 
arrive in, what format to translate it to, and how many 
transactions to bill a data-receiving subscriber for. The 
system performs data translation and transfer, and performs 
validation, exception reporting, data analysis, and generates 
and sends receipts. Some or all such data processing may 
alternatively be performed at one or both of the data source 
and the data destination, without an intermediate processing 
location. A provider data file may also be prepared from a 
scanner, such as a fax transmission, which provides image 
data which are processed in order to derive the data file. 

28 Claims, 16 Drawing Sheets 
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Figure 2A 





fo o o ol)- 









MidFormat Files 34? sent 
and Receipt Returned 

' [QQOQ 



□ 



Provider Section 10 with 
integral Main Processing 
Section 20 



Subscriber Section 30 



Figure 2B 



□ 



Provider Section 1Q 



Provider Da ta Files 115 
Provider's Data Format 
116 sent and Receipt 
Returned 



in 



□ 



Subscriber Section 3Q with 

integral Main Processing 

Section 20 



Figure 2C 



□ 



Destination Format Files 610 
sent and Receipt Returned 



Provider Section 10 with integral 
Main Processing Section 20 plus 
integral Postprocessors 601 



Subscriber Section 30 without 
Postprocessors 601 



02/24/2004, EAST Version: 1.4.1 



U.S. Patent 



Mar. 4, 1997 



Sheet 3 of 16 



5,608,874 




02/24/2004, EAST Version: 1.4.1 



U.S. Patent 



Mar. 4, 1997 



Sheet 4 of 16 



5,608,874 



Figure 4: Details of Block 100 
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FIGURE 5A: Detail of Block 200 
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FIGURE SB: Detail of Block 200 
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FIGURE 6C-1 
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FIGURE 6C-2 
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FIGURE 7A: Detail Block 400 
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FIGURE 7B: Detail of Block 400 
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Figure 8: Details of Block 500 
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SYSTEM AND METHOD FOR AUTOMATIC 
DATA FILE FORMAT TRANSLATION AND 
TRANSMISSION HAVING ADVANCED 
FEATURES 

5 

RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. appli- 
cation Sen No. 08/349,022 filed Dec. 2, 1994. 

10 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The field of the present invention relates to automated 
data transfer and translation. The invention provides a is 
method and structure for automatically transferring data, 
such as accounting data, from a variety of remote sources, in 
a variety of formats to a plurality of remote sites, where the 
data is entered into computer applications or storage, the 
transfer including format translation for compatibility. The 
invention serves as means to eliminate time-consuming and 
error-producing manual data re-entry. 

2. Background 

Computerized data, or electronically stored information, 
must frequently be moved from one computer to another. In 
the case of accounting data, for example, banks generally 
keep computerized records of all of transactions affecting 
their client's accounts — information which the clients often 
also wish to keep track of on their own computerized 
accounting systems. In response to this, a variety of sophis- 
ticated computer accounting programs have recently 
become available to users of small and medium powered 
computers. However, due to a variety of reasons discussed 
below, such clients usually have to re-enter data manually 
from paper printouts obtained from the data provider, for 
example, from statements from a bank. Manual re-entry of 
data is not only time-consuming, and hence expensive to 
undertake in terms of man-hours, but it also is likely to 
introduce errors into the data set. It has been estimated that 
manual data re-entry, verification, and validation costs sev- 
eral dollars per transaction. 

Methods of automated data transfer are known in the art. 
The "Intellicharge" system for Quicken (Intuit Inc., Menlo 
Park, Calif.) downloads credit card transaction information 
to a Quicken user's computer. The data used, however, 
comes from a uniform source — a single bank. Hence, Intel- 
licharge does not employ a multiple-format data translation 
scheme, nor a multiple-source data transmission scheme. 
Similarly, in the United States Internal Revenue Service 
"Electronic Filing" program, data is entered and transmitted 
in a single, specific pre-prescribed format, to a single 
recipient 

Methods of data translation are also known in the art. A 
software application entitled "Data Junction" (Tools and 
Techniques, Inc., Austin, Tex.) translates multiple formats of 
data. However, the package depends on manual operation to 
designate the files to be translated, and the formats of the 
source and destination files. Furthermore, this software does 
not perform any data transfer, verification, validation, excep- 60 
tion reporting, or journal entry correction. 

Conventional electronic data exchange (EDI) systems 
involve two or more companies that have agreed to interact 
with one another according to a pre-designated standard 
dictated by the industry in which the transaction is taking 
place. In order for such a system to work for a given 
industry, there must be an agreed-upon standard that is 
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used-much like in the case of the IRS system described 
above. Those industries that do not have such a standard 
cannot participate. Data analysis, such as exception report- 
ing or statistical analysis, are not features of such systems. 
Obviously, such systems lack flexibility and versatility. 
Additionally, the computer systems that support conven- 
tional EDI are expensive to operate and maintain because 
they are specialized to serve specific industry segments, and 
hence cannot achieve the efficiency and low cost that econo- 
mies of scale might permit in a more widely applicable 
system. 

In summary, conventional methods of automated data 
transfer, and of data translation, are quite limited, due 
primarily to limited network transfer capabilities, and the 
lack of universal data format standards. Hence, anyone 
wishing to automatically transfer data from a variety of 
computer systems to a variety of others must contend with 
a plethora of incompatible formats, and a lack of reliable 
transfer and error detection means. For these reasons, exist- 
ing data transfer systems have been tailored to work with 
only one, or very few types of data sources and recipients, 
and these data translation methods rely heavily on manual 
intervention. Data transfer technologies and data translation 
technologies have not, in the prior art, been efficiently 
integrated. 

OBJECTS AND SUMMARY OF THE 
INVENTION 

As can be appreciated from the foregoing discussion, it 
would be desirable to have a flexible transfer and translation 
system that would operate on a wide variety of formats, not 
hampered by the lack of data format standards — a system 
that takes data in any format, transfers it to a remote 
location, and inserts it into the software application in which 
the data is needed. It would be desirable for a system to 
automatically understand what specific format translations 
are needed for a specific data recipient, then to be able to 
automatically carry out such a translation regardless of what 
format the data was originally in. It would also be desirable 
for such a system to operate with minimal user interaction, 
making it faster, cheaper, and more reliable than manual or 
semiautomatic performance of such tasks. It would also be 
desirable to enable companies that want to make their 
computerized data available to outside agencies and indi- 
viduals to be able to export this data without the time and 
expense of developing a custom export system. It would also 
be desirable to have such a system that is modular and 
scalable on hardware and software levels, so as to provide 
reliability, serviceability, and adjustability of the system's 
performance. The present invention fills these aforemen- 
tioned needs. 

The present invention/in one embodiment, comprises a 
system capable of automatically receiving, at an intermedi- 
ate processing location, data from a wide variety of remote 
sources, identifying the format of the data, translating the 
data to a common format, sending the data to a recipient in 
an intermediate format, then translating the data to the 
specific format needed by the particular recipient. A unique 
system for automatically selecting and implementing spe- 
cific translation modules may be used. Error checking fea- 
tures ensure that the transferred data matches the original 
data, and receipts are sent to each section of the system that 
sends data, and logical, statistical and mathematical opera- 
tions may be performed on the data. The system utilizes 
internal databases which allows it to know what format data 
will arrive in, what format to translate it to, and how many 
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transactions to bill a data-receiving subscriber for. The 
system performs data translation and transfer, and performs 
validation, exception reporting, data analysis, and generates 
and sends receipts. In alternative embodiments, some or all 
such data processing is performed at one or both of the data 
source and the data destination, . without an intermediate 
processing location. 

In an alternative embodiment, a provider data file is 
prepared from a scanner, such as a fax transmission, which 
provides image data which are processed in order to derive 10 
the data file. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates the physical apparatus of one embodi- 15 
ment of the invention. 

FIGS. 2A, 2B, and 2C illustrate the major aspects of the 
physical apparatus and spacial layout of some alternative 
embodiments. 

FIG. 3 shows an overview of an embodiment of the 
system architecture from the standpoint of process. Each 
block within this figure corresponds with one or more 
detailed separate figures. 

FIG. 4 shows one embodiment of the major components 
and processes which occur at block 100 of FIG. 3. 

FIG. 5 shows one embodiment of the major components 
and processes which occur at block 200 of FIG. 3, 

FIGS. 6A, 6B, and 6C show some embodiments of the 
major components and processes which occur at block 300 
of FIG. 3. FIG. 6A focuses on the role of the PrepServer 
Software. FIG. 6B focuses on the role of a selected Prepro- 
cessor. FIG. 6C illustrates some of the components utilized 
in FIG. 6B. 



BRIEF DESCRIPTION OF THE TABLES 

Table 1 shows one embodiment of the Subscriber Data- 
base Key to the Master Customer Definition Table. 

Table 2 shows one embodiment of the Subscriber Data- 
base Key to the Master Mailbox Definition Table. 

Table 3 shows one embodiment of the Subscriber Data- 
base Key to the Transactions Table for Tracking and 
Accounting. 

Table 4 shows one embodiment of the Subscriber Data- 
base Key to the System Log File. 

Table 5 shows one embodiment of the Subscriber Data- 
base Key to the Incrementing Batch ID Number. 

Table 6 shows sample Preprocessor Command-Line 
Arguments. 

Table 7 shows an example of the layout of a payroll file 
received from a Data Provider. 

Table 8 shows an example of the layout of a bank account 
file received from a Data Provider. 

Table 9 shows an example of the layout of a Midformat 
payroll file. 
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FIG. 7 shows one embodiment of the major components 35 
and processes which occur at block 400 of FIG. 3. 

FIG. 8 shows one embodiment of the major components 
and processes which occur at block 500 of FIG. 3. 

FIG. 9 shows one embodiment of the major components 
and processes which occur at block 600 of FIG. 3. 

FIG. 10 shows one embodiment of this invention in which 
a scanner, such as a fax machine, is used to provide data 
from a printed document 
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Table 10 shows an example of the layout of a Midformat 
bank account file. 

Table 11 shows an example of the layout of a Destination 
Format payroll file. 

Table 12 shows an example of the layout of a Destination 
Format bank account file. 



DETAILED DESCRIPTION 



Definitions and Terminology 

ComServer Host — A machine on which the ComServer 
Software is operating, allowing the machine to control the 
telecommunication operations of a networked, distributed- 
task version of the Main Processing Section. 

ComServer Software — ^Telecommunications software, in 
some embodiments residing on a ComServer Host computer, 
which receives remotely transmitted data and stores it. It 
may also transmit processed and unprocessed data to remote 
sites. Such a system is similar to a computerized mail box 
system as commonly seen in on-line services such as 
America Online (Vienna, Va). ComServer Software func- 
tions may be carried out by commercially available software 
packages such as WildCat! BBS (Mustang Software, 
Bakersfield, Calif.) 

Data Provider File Management Program — A system 
which enables a user of a Provider Section to connect to the 
Main Processing Section, and to transmit Provider Data 
Files, store copies of data files that have been sent, and 
which stores data transmission receipts. 

Data Validation— Comparison of a data set and a refer- 
ence data set, including calculated or otherwise derived data, 
to assess the correctness of the data content of a file. An 
example is making sure that a specific debit was for a certain 
amount of money. 

Data Verification — Comparison of a data set with a ref- 
erence data set or value to assess the completeness of the 
data set's structure. An example is screening for a checksum 
error. 

Destination Address — Information that tells the system to 
whom a data file is to be sent, and therefore, it which 
Outgoing Data Box it is to be placed. 

Destination Format — The data format required or 
requested by the Subscriber. Postprocessors translate Mid- 
Format Files into Destination Format files, and load them 
into the Subscriber's application software. 

Environment Directory — The directory where initializa- 
tion files, system logs, etc, are kept. 

Exception Report — The user report which displays errors 
or warnings related to transactions that have been processed. 

Failed Data Box — A subdirectory used to contain files 
that were not successfully processed or transmitted at a 
given location in the system. 

Firewall — Security methods which protect a computer 
system from access, using hardware or software measures. A 
firewall may be a barrier set up to keep designated Local 
Area Network (LAN) traffic within an/or without a specific 
LAN. For example, a firewall can be set up to stop internal 
e-mail from leaving a LAN, or can be set up to keep outside 
users from connecting to computers within a LAN. 

History Data Box — A subdirectory used to contain files 
that have been successfully processed or transmitted at a 
given location in the system. 



02/24/2004, EAST 



Version: 1.4.1 



5,608,874 



Mail Box Database — The Main Processing Section data- 
base that contains records of Incoming and Outgoing Data 
Boxes, and to what party they pertain. 

Main Processing Section (MPS) — Portions of the inven- 
tion herein described that are responsible for tasks such as 5 
data translation, system usage monitoring, and exception 
reporting. In one embodiment, the Main Processing Section, 
including PrepServer Software and/or it's Preprocessors 
and/or the ComServer Software, and/or Billing and Admin- 
istrative System resides at a site separate from the sites of the i 0 
Provider Section and the Subscriber. In one such embodi- 
ment, data received from the Provider is processed by the 
Main Processing Section to provide translated data. This 
translated data is then sent on to a Subscriber who translates 
the data again. In alternative embodiments, the Main Pro- 
cessing Section and/or some or all of it's components may 15 
reside on either the Provider or Subscriber computers, or 
split between them, thus eliminating the intermediate site, or 
reducing the amount of processing that takes place at such 
an intermediate site. 

MPS Incoming Data Box— The subdirectory in which 20 
Provider Data Files are placed when it arrives from a specific 
provider. 

MPS Outgoing Data Box— The subscriber-specific sub- 
directory in which MidFormat Files are placed when PrepS- 
erver has successfully processed the file. 25 

MidFormat File — A data file that has been translated into 
a format common to all data files of that particular type, prior 
to being converted to a Destination Format. It originates as 
a translated Provider Data File created by the Preprocessor, 3Q 
and it contains a list of delimited transactions. This file is 
translated by the Postprocessor into a Destination Format in 
order to load it into a Subscriber's application software. 

Number of Transactions— A tally internal to each Prepro- 
cessor which counts the number of transactions that are 35 
processed. 

Postprocessor — A program which translates a MidFormat 
File into the specific Destination Format required by a 
Subscriber, and loads the Destination Format data into 
Subscriber's Application Software. 40 

Preprocessors — Software programs controlled by the 
PrepServer Software, which automatically perform data 
format translations for specific Data Providers. These pro- 
grams translate Provider Data Files into MidFormat Files, 
and record the number of transactions processed into a 4 * 
Transactions Table. 

PrepServer Host— A machine in which PrepServer Soft- 
ware is the principal software, allowing the machine to 
specialize in the PrepServer Software tasks of a networked, 
distributed version of the Main Processing Section. 50 

PrepServer Software — Software, in some embodiments 
residing on a PrepServer Host computer, which takes 
unprocessed data from the ComServer Software by scanning 
Incoming Data Boxes for received Provider Data Files. If 
found, the PrepServer Software processes the data with a 
specific set of instructions (for example, by selecting the 
appropriate Preprocessor), and places the data in a specific 
MPS Outgoing Data Box mapped to the data's ultimate 
destination. 

60 

Provider — A Data Provider. A company which sends 
transaction data to the Main Processing Section. An example 
is a bank which electronically transfers account statements. 
Another example is a laboratory which electronically trans- 
fers the results of it's blood sample analysis. 65 

Provider Data File — A file uploaded into a mailbox by a 
Provider containing a list of transactions in the Provider's 
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data format. This file will be translated by the Preprocessor 
into a MidFormat File. Also known as a Raw Transactions 
File (RTF). 

Provider History Box— The subdirectory in which a Pro- 
vider Section retains a copy of files that have been success- 
fully transferred to the Main Processing Section. 

Provider Outgoing Data Box— The subdirectory in which 
a Provider Section places Provider Data Files that are ready 
for transmission. 

Provider Section— That hardware and software portion of 
the system herein described which reside at physical loca- 
tion of the Data Provider, usually including telecommuni- 
cations software and Provider Data Files to be transferred. 

Raw Transactions File (RTF) — See Provider Data File. 

Subscriber — Also known as Data Subscriber. The end- 
recipient of the data in the herein described system. A 
Subscriber has Subscriber's Application Software (such as a 
financial software package) which can make use only of data 
files that are in certain formats. The subscriber wishes to 
have data residing at a the Provider Section to be sent to him, 
and to be translated in a format that is suitable for use by his 
application software. 

Subscriber's Application Software — A computer applica- 
tion program, such as accounting packages like Platinum 
(Platinum Software, Irvine, Calif.) into which a Subscriber 
wishes to enter data. Subscriber's Application software 
typically requires data to be in a specific format before it can 
be accepted. 

Subscriber ID — The unique identification key assigned to 
each subscriber. 

Subscriber Incoming Data Box— The Subscriber Section 
subdirectory in which MidFormat files transmitted from the 
Main Processing Section first arrive, and where they can be 
found by the Postprocessor. 

Subscriber Section— Those hardware and software por- 
tions of the system herein described that reside at the 
physical location of the Data Subscriber, usually including a 
Postprocessor program. 

Subscriber Table — A database file containing subscriber 
information such as Subscriber ID number, Subscriber 
Name, Job Number, Translation Information, Subscriber 
Destination Address, and subscriber Filename Information. 

Syslog — A file, such as one in the environment directory, 
used to record system activity. 

Table — Depending upon the context, this term may refer 
to a display of information used as an exhibit for this patent 
application, or may be used to mean a database file. 

Test Result Report— A report for the user of a subscriber 
Section displaying errors and warnings related to user spe- 
cific transactions. Statistical and Boolean logic data valida- 
tion methods may constitute the basis of the report. 

Test Result Database — A Database storing the validation, 
statistical, and Boolean calculations and algorithms neces- 
sary to produce a Test Result Report. 

Transaction — Data representing a specific activity, entity, 
or portion thereof. Examples include financial transactions 
such as: a check item debit in a bank statement, a credit debit 
in a VISA statement, or a shipping charge in a Federal 
Express bill, and non-financial transactions such as labora- 
tory test results sent from a laboratory to a hospital. 

Transaction Type — A unique type of transaction, e.g. a 
line-item in a customer bill. 

Transmission Receipt — An electronic document which 
serves to notify a user as to whether a data transmission has 
been successfully or unsuccessfully transmitted. 
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Transmission Receipt Database — A database storing all 
Transmission Receipts received. 

Transactions Table — The database file containing a list of 
processed transactions for all Subscribers. 

User— A person who is operating a specified section of 5 
the system herein described, at a given time. 

Work Directory— A temporary directory created by the 
PrepServer Software and used by the Preprocessor as work 
space in which to carry out data translation and manipulation 
processes. * 0 

Description of Exemplary Embodiments 

In the foregoing definitions, it should be appreciated that 
the system herein described is composed of subsystems 15 
which perform their tasks simultaneously, or in a rapidly 
alternating, interactive fashion. Because a written specifica- 
tion requires putting these parallel processes into a linear 
explanation, discussions of such processes are presented 
here in a manner that requires moving back and forth 20 
between figures, system components, events, and stages 
within the processes. 

In one embodiment, shown in the block diagram of FIG. 
1, the system of the present invention extends over three or 
more sites — that of one or more Provider Sections 10, that 
of Main Processing Section 20, and that of one or more 
Subscriber Sections 30. These sites are linked, for example, 
by telecommunication methods such as modems (depicted 
as Telecommunications Links 11 and 21). 
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At Provider Section 10, Computer 52A may be one such 
as an IBM-compatible PC with a CPU such as Pentium Chip 
(Intel Inc., Santa Clara, Calif.), Main Memory such as 
Random Access Memory in quantities such as 8 Megabytes, 
and with peripheral devices such as a Monitor (NEC, 
Woodale, 111.), a Mouse (Microsoft Corp., Redmond, Wash.), 
a Keyboard (Microsoft Corp., Redmond, Wash.), Mass 
Storage such as a hard drive (Maxtor, San Jose, Calif.) or 
other mass storage. Telecommunication Means such as 
Modem 54J, such as the Sportster 14.4 (U.S. Robotics, ^ 
Skokie, HI.) may be used. The modem requires the use of 
telecommunications software such as that provided RipTerm 
and RipPaint (Telegraphies, Huntington Beach, Calif.). The 
computer may use an operating system such as MS-DOS 6.0 
(Microsoft Corp., Redmond, Wash.). A Printer such as one 
by Hewlett-Packard (Boise, Id.) may also be attached. 

Hardware and software components in the telecommuni- 
cation-linked system herein described can be relocated to 
various physical locations and still perform their respective 
functions, as will be shown in the discussion of FIGS. 50 
2A-2C. With the exception of the FIGS. 2A-2C discussion, 
however, for the purposes of further discussion in this 
document, an embodiment of the Provider Section 10 will be 
considered to include Provider Section Telecommunications 
Software, a Data Provider File Management Program, Pro- 55 
vider data Files, and hardware such as that previously 
described. 

In one embodiment, at Main Processing Section 20, there 
are preferably two or more computers joined together in a 
network, using standard hardware such as an Ethernet card 60 
(Western Digital, Irvine, Calif.), and software such as Net- 
ware 3.1 by Novell Inc., (Provo Utah). A first computer, 
ComServer Most 76A, operates under the control of Corn- 
Server Software, described later, allowing it to specialize in 
communications via links 11 and 21, with other computers, 65 
such as Provider Section 10, PrepServer Most 78A, and 
Subscriber Section 30. A second computer, PrepServer Host 



78A operates under the control of PrepServer Software, later 
described, which enables PrepServer Host78A to specialize 
in data processing. ComServer Host 76A, and PrepServer 
Host 78A may each have the same hardware and operating 
system as the computer above described at Provider Section 
10, except, of course, that ComServer Host 76A, and PrepS- 
erver Host 78A will also run the specialized software 
programs collectively referred to as ComServer Software 
and PrepServer Software. As an addition exception, only 
ComServer Host 76A requires a modem if both PrepServer 
Host 78A and ComServer Host 76A are used together. 
Multiple Modems 54A connected to the network via Mul- 
tiplexer 74B such as the Wildcat! BBS IM, MultiPort 
multiplexer (Mustang Software, Bakersfield, Calif.) may be 
used in order to improve the efficiency of remote data 
reception and transmission from multiple parties simulta- 
neously. 

Hardware and software components in the telecommuni- 
cation-linked system herein described can be relocated to 
various physical locations and still perform their respective 
functions as will be shown in the discussion of FIGS. 
2A-2C. With the exception of the FIGS. 2A-2C discussion, 
however, for the purposes of further discussion in this 
document, an embodiment of the Main Processing Section 
20 will be considered to include ComServer Software, 
PrepServer Software, Preprocessors, Billing and Adminis- 
trative System, and hardware such as that previously 
described. 

At Subscriber Section 30, the computer hardware and 
software may be exactly the same as that described for 
Provider Section 10. Additionally, the User of Subscriber 
Section 30 will have application software which requires 
input data flies to be in a certain formats— hence giving the 
User of Subscriber Section 30 the need for using the system 
herein described. Examples of such Subscriber's Applica- 
tion Software include the accounting package called Plati- 
num (Platinum Software, Irvine Calif.), spreadsheets such as 
Excel (Microsoft Corp., Redmond Wash.), and databases 
such as dbase (Borland, Scotts Valley, Calif.). 

Hardware and software components in the telecommuni- 
cation-linked system herein described can be relocated to 
various physical locations and still perform their respective 
functions as will be shown in the discussion of FIGS. 
2A-2C With the exception of the FIGS. 2A-2C discussion, 
however, for the purposes of further discussion in this 
document, an embodiment of the Subscriber Section 30 will 
be considered to include Subscriber Telecommunication 
Software, MidFonnat Files, at least one Postprocessor, 
Subscriber's Application Software, and hardware such as 
that previously described. 

A set of data that a Provider Section 10 sends to Main 
Processing Section 20 is called Provider Data File 115. The 
content of Provider Data File 115 may be accounting and 
financial information including but not limited to payroll 
transactions, bank transactions, bills, and cash receipts. The 
data may also be any of a wide variety of non-financial 
types, such as the values that a laboratory has found for 
specific attributes of a patient's blood sample, such as 
hemoglobin, hematocrit, sodium, potassium, and chloride 
levels. The format of these data can be divided into general 
categories, including, but not limited to ASCII, ANSI X.12, 
EDIFACT, Binary Files with Headers, graphics files, sound 
files, video files, and alternate compression method files. 
Such general categories may be further subdivided into an 
array of different formats. ASCII, or EBCDIC files, for 
example, may appear in several formats including, but not 
limited to Carriage return, Line Feed, Fixed Width without 
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Carriage Return, and delimited files. The particular format 
of a Provider Data File 115 is generically referred to herein 
as the Provider's Data Format. Regardless of the format 
used, a Destination Address 117, which describes who the 
data is for, accompanies the actual data within Provider Data < 
File 115. 

In a typical pattern of information flow, a Provider Data 
File originating on Computer 52A of Provider Section 10 is 
sent via Modem 54J and Telecommunications Link 11 to 
Main Processing Section 20 via an array of one or more iq 
Modems 54A through 541 and Multiplexers 74 coordinated 
by one or more CamServer Hosts 76A, 76B, 76C. After the 
data file is processed in an associated one of PrepServer Host 
78A, 78B, 78C, the data, now in the form of a MidFormat 
File, is sent via one or more ComServer 76A, 76B, 76C, and 15 
the multiplexed array of one or more Modem 54A through 
541, through Telecommunication link 21 to Subscriber Sec- 
tion 30, where the data is further translated, if necessary, and 
utilized within a computer application. Box 40 represents 
the numerous other Provider Sections and Subscriber Sec- 20 
tions with which the system may simultaneously or sequen- 
tially interact. 

FIGS. 2A, 2B, and 2C illustrate alternative configurations 
for the physical location of the system's components, in 
which there are two rather than three sites through which 25 
data must pass. Specifically, Main Processing Section 20 
does not have a separate physical location, and instead 
resides in Provider Section 10 only, or Subscriber Section 30 
only. Main Processing Section 20 may also be parceled 
between Provider Section 10 and Subscriber Section 30. 30 
Furthermore, other components such as Subscriber Section 
30 may be parceled. As long as the components are some- 
where on the system, all necessary tasks can be accom- 
plished in accordance with this invention. Thus, a given data 
file may be transmitted directly from Provider Section 10 to 35 
Subscriber Section 30, with the appropriate translation being 
provided. 

In FIG. 2A, Provider Section 10 uses Main Processing 
Section software on it's own computer data storage device 
such that it can send MidFormat Files to Subscriber Section 40 
30, which can subsequently use Postprocessors to bring the 
data into the required format for loading it into the Sub- 
scriber' s Application Software. 

In FIG. 2B, Subscriber Section 30 has Main Processing 
Section 20 within it, in addition to it's usual components. 45 
With the system configured in this manner, Subscriber 
Section 30 can receive files in their native Provider's Data 
Format, and perform all necessary processing, including 
translation, on site. 

50 

In FIG. 2C, Provider Section 10 has incorporated not only 
the components of Main Processing Section 20, but also 
Postprocessors. In this configuration, Provider Section 10 
can send Destination Format files to Subscriber Section 30, 
ready to be used by the Subscriber's Application Software. 35 

Of course, there are a wide variety of intermediate varia- 
tions possible in which various components of the invention, 
such as PrepServer Software, Preprocessor, and Postproces- 
sor, reside on the different machines through which infor- 
mation passes. It can be appreciated that cooperative behav- ^ 
ior of the multiple computers interacting under the directions 
of the invention's software makes the physical location of 
any given component unimportant to the overall process. 

When the system is implemented without a separate 
location for Main Processing Section 20, a separate Com- 65 
munications Server Host 76 computer may not desirable, 
since a smaller volume of transmissions will likely pass 
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through Main Processing Section 20, increasing the feasi- 
bility of more simple telecommunications setups. 

FIG. 3 shows an overview of one embodiment, demon- 
strating the main features of the system architecture at a 
process level, each block corresponding to one or more 
detailed Figures on successive sheets of the drawings. In 
Block 100 activities occurring at Provider Section 10 are 
highlighted, and is detailed in FIG. 4. Blocks 200, 300, and 
400 highlight activities occurring at Main Processing Sec- 
tion 20, and are further detailed in FIGS. 5, 6A-C, and 7, 
respectively. Blocks 500 and 600 highlight activities occur- 
ring at subscriber Section 30, and are further detailed in 
FIGS. 8 and 9, respectively. 

In Block 100, Provider Data Files 115 generated by Data 
Provider 113, and residing on Provider Section 10 are 
transmitted to Main Processing Section 20 via Telecommu- < 
nications Link 11. 

In Block 200, Provider Data Files 115 received via 
Telecommunication Link 11 and ComServer Software 201 is 
stored in MPS Incoming Data Box 355. 

In Block 300, PrepServer Software 354 copies Provider 
Data File 115 from MPS incoming Data Box 355, to Work 
Area 366. Subsequently, the file is format-translated from 
the native format of Provider Data File 115, to that of a 
MidFormat File 342. This resultant MidFormat File 342 is 
then moved to MPS Outgoing Data Box 371. 

In Block 400, ComServer Software 201 at Main Process- 
ing Section 20 forms Telecommunications Link 21 with the 
telecommunications software of Subscriber Section 30. 
MidFormat Files 342 that are in MPS Outgoing Data Box 
371 which correspond to the particular Subscriber Section 
30 with which contact is made, are transmitted over Tele- 
communications Link 21, to Subscriber Section 30. 

In Block 500, Subscriber Section 30 receives MidFormat 
Files 342 from Main Processing Section 20, and stores these 
files. 

In Block 600, Postprocessor 60 translates MidFormat 
Files 342 into Destination Format Files 610 — the format 
needed by Subscriber Application Software 620. Destination 
Format Files are then inserted into Subscriber Application 
Software 620. 

FIG. 4 shows in more detail one embodiment of events 
occurring within Block 200 of FIG. 3. Steps 110, 120, 130, 
180, and 190 collectively form Data Provider File Manage- 
ment Program 105. Data Provider File Management Pro- 
gram 105 works in conjunction with Provider Section Tele- 
communication Software 142. Of course, these programs 
typically run concurrently with Main Processing Section 
telecommunications software while data is being down- 
loaded—a process shown in detail in FIG. 5. 

In step 110, Provider Data Files 115 are generated by Data 
Provider 113 by means well known in the art. One simple 
example of this is a Data Provider 113 manually entering 
data pertaining to a specific Data Subscriber into a database 
application such as dbase (Borland, Scotts Valley, Calif.). 
Adding a Destination Address 117 to such a data file is 
performed by a variety of means, including simply typing in 
an alphanumeric string into a designated field of the file, the 
string being uniquely representative of the specific Sub- 
scriber that the data is intended to ultimately reach. An 
example of this is a bank that enters the social security 
number of a client into a certain field of their file of cleared 
bank checks. In step 120, Provider Data File 115 with 
Destination Address 117 is loaded into Provider Section 10 
computer, into Outgoing Data Box 128. Here, this particular 
process halts, and does not proceed to step 130, until 
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prompted by Provider Section Telecommunications Soft- 
ware 142. Provider Section Telecommunications Software 
142 is initiated in step 140 by any of a variety of methods, 
including being set to initiate at a specific time, and initiating 
when a call is received from ComServer Software 201 of 5 
Main Processing Section 20. These methods are discussed in 
detail in the discussion of FIG. 5, steps 235 and 245. The 
basic problem that all of these methods address is that the 
quality of data ultimately delivered to Data Subscribers 33 
must be ensured. Not having safeguards would be to risk 
obtaining an incorrect or error-ridden data set — either acci- 10 
dentally or by the intent of some third party posing as a 
provider. Similarly, a party other than the correct Subscriber 
Section 30 must not be allowed to receive proprietary and 
potentially sensitive data files belonging to another. Hence, 
caller validation procedures, coordinated, for example, by 15 
Main Processing Section 20, become important. 

In one embodiment, the data transmission process is 
invoked in step 140, where the uploading process is initiated 
via Telecommunications Software 142. In step 150, Provider 
113 connects with ComServer 152 and upon being validated 20 
by the methods discussed in the description of FIG. 5, 
receives clearance to transmit a copy of Provider Data File 
115 to Main Processing Section 20. At this point Provider 
Data Files 115 that had been placed in Provider's Outgoing 
Data Box 128 in step 120 are read in step 170, copies being 25 
transmitted in step 160 over Telecommunications Link 11, to 
Main Processing Section 20. In step 180, Telecommunica- 
tions Software 142 determines whether a copy of Provider 
Data File 115 has been transmitted successfully. Successful 
data transmission is signaled to Main Processing Section 20 30 
by a response produced by the modem protocol. Most 
standard modem protocols including X, Y, and Z modem 
protocols have internal error checking means to carry out 
such a signaling process. If Provider Data File 115 has been 
successfully transmitted, then the Provider Data File 115 35 
duplicate remaining in Outgoing Data Box 128 is "moved" 
to History Data Box 135 in step 130, for example by simply 
renaming the subdirectory. If Provider Data File 115 is not 
successfully transmitted, then an error appears in Provider 
Error Log 187, in step 185. Data Provider File Management 40 
Program 105 is thus completed. 

Using a modem, Provider Section 10 can either directly 
transmit Provider Data Files 115 to Main Processing Section 
20, or electronically mail this information. Of course, there 
are many other means of electronic data transmission known 45 
in the art that are also suitable for this purpose, within the 
framework of the present invention. Any of a variety of 
modem protocols may be used, such as X, Y, or Z modem 
protocols. 

Alternative methods of communication and electronic 50 
mail between separately located sections of this system 
include the use of on-line services such as CompuServe, 
America Online, Prodigy, or infrastructures such as the 
Internet, or the Information Superhighway, each with their 
respective electronic mail and file transfer capabilities. 

In another alternative embodiment, non-modem transmis- 
sion means such as ISDN, and Internet IP/FTP transmit the 
data from Provider Section 10 to Main Processing Section 

20 60 

The iriformation transmitted by Provider Section 10 can 
be encrypted with a combination of security techniques, 
including, but not limited to data encryption and security 
measures. Methods of data encryption are well known in the 
art. Examples of data encryption methods are RSA Data 65 
Security (Redwood City, Calif.) software solutions, and the 
use of the proposed "Clipper" chip hardware solution. 
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Data Provider Telecommunications Software 142 used to 
support the telecommunication links necessary to transfer 
Midformat Files 342 from Provider Section 10 to Main 
Processing Section 20 may be one such as RipTerm 
(TeleGrafix Communications Inc., Huntington Beach, 
Calif.). A simple user interface that gives the necessary 
instructions to the telecommunications software to carry out 
the previously tasks may be assembled by well-known 
methods using software such as RipPaint (TeleGrafix Com- 
munications Inc., Huntington Beach, Calif.). 

FIG. 5 details an embodiment of Block 200 of FIG. 3, in 
which ComServer Software 201 at Main Processing Section 
20 receives Provider Data files 115, and stores them in a 
specific MPS Incoming Data Box 355. 

In step 205, ComServer Software 201 is started by the 
user of Main Processing Section 20. 

In step 210, ComServer Software 201 continuously scans 
modems 54 and multiplexers 74 for a Provider 12. In an 
alternative embodiment, ComServer Software 201 scans 
modems 54 and multiplexers 74 for a Provider 12 at pre- 
determined time intervals. In another alternative embodi- 
ment, ComServer Software 201 scans modems 54 and 
multiplexers 74 for a Provider 12 at the command of a Main 
Processing Section 20 user. 

In Step 215, ComServer Software 201 determines 
whether a Provider Section 10 is calling Main Processing 
Section 20, requesting a connection. 

In Step 220, ComServer Software 201 determines that a 
call is not made, or that program termination has been 
otherwise requested. 

In Step 225, ComServer Software 201 is terminated, as it 
has been instructed by the program's flow. In an alternative 
embodiment, ComServer Software 201 is terminated on 
demand by Main Processing Section 20 user. 

In Step 230, ComServer Software 201 activates the Bill- 
ing and Administrative System 373 database. This database 
stores information regarding all valid Providers 12, their 
respective Provider Sections 10, and corresponding pass- 
words and security levels. 

In Step 235, ComServer Software 201 accesses Billing 
and Administrative System 373 database to lookup and 
determine whether the calling party is a valid Provider 
Section 10. 

Step 240 shows an example of a calling party dialing into 
Main Processing Section 20. 

In Step 245, ComServer Software 201 determines 
whether to allow the calling party to connect to Main 
Processing Section 20 based upon the security password and 
security level. 

In Step 250, ComServer Software 201 disconnects from 
invalid calling parties. In one embodiment, ComServer 
Software 201 records the calling party phone number along 
with a date-stamp and time-stamp in the Billing and Admin- 
istrative System 373 database. Finally, ComServer Software 
201 prepares to scan and detect the next, calling party. 

In Step 255, ComServer Software 201 connects to valid 
Provider 12 and grants Subscriber Section 30 access to the 
Main Processing Section 20. ComServer Software 201 then 
responds to Provider 12 request to receive Provider Data 
File 115. 

In step 260, ComServer Software 201 determines which 
Provider 12 MPS Incoming Data Box 355 should be used 
and begins storing Provider Data File 115. 

In Step 270, ComServer Software 201 sends a Data 
Transmission Receipt 202 to Provider Section 10. This 
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receipts tells Provider 12 whether Provider Data File 115 
transmitted successfully. Finally, ComServer 201 discon- 
nects from Provider 12 and prepares for the next caller. 

ComServer Software 201 is used to support the telecom- 
munication links necessary to receive MidFormat Files 342 5 
from Provider Section 10 to Main Processing Section 20 
may be one such as RipTerm (TeleGrafix Communications 
Inc., Huntington Beach, Calif.). A simple user interface that 
gives the necessary instructions to the telecommunications 
software to carry out the previously tasks may be assembled jq 
by well-known methods using software such as RipPaint 
(TeleGrafix Communications Inc., Huntington Beach, 
Calif.). 

Validation, as shown in Step 235 is performed in any of 
a variety of ways. In one embodiment, Main Processing 15 
Section 20 employs the caller identification method to 
determine whether the caller is valid. By this caller ID 
method, the telephone number of any party attempting to 
establish connection with Main Processing Section 20 is 
screened by Main Processing Section 20 by matching the 20 
telephone number of the caller to a list of valid Provider 
numbers. This valid number list is maintained by a database 
internal to Main Processing Section 20, to ensure that the 
calling party is a valid Provider Section 10. If the telephone 
number is not that of a valid Provider Section 10, Main 25 
Processing Section 20 does not establish a connection, and 
Main Processing Section 20 time-stamps, date-stamps, and 
records that invalid phone number. If the number captured, 
on the other hand, represents a valid Provider Section 10, 
Main Processing Section 20 allows the transfer of Provider 30 
Data files 115 from Provider 10 to Main Processing Section 
20. 

In an alternative embodiment, Main Processing Section 
115 prompts Provider Section 10 for a valid log-in name 
and/or a password. The password is preferably changed 35 
frequendy. The entry of a log-in name and/or password may 
be automatic or manual on the part of Provider Section 10. 

In an alternative embodiment, data transmission is initi- 
ated by a call from Main Processing Section 20 to Provider 
Section 10, rather than vice-versa. 40 

In an alternative embodiment, a connection between Pro- 
vider Section 10 and Main Processing Section 20 is estab- 
lished upon securing access through existing security sys- 
tems such as a Firewall. 

45 

In an alternative embodiment, the "call-back" method is 
used. In this case, Provider Section 10 establishes a con- 
nection with Main Processing Section 20. Main Processing 
Section 20 verities the validity of Provider Section 10 by 
means such as those described above. The communication 
link is then disconnected. Next, Main Processing Section 20 
calls back to, and connects with Provider Section 10, and 
proceeds to download Provider Data Files 115. The need for 
a call to be returned by the prospective data recipient (in this 
case, Main Processing Section 20) provides an additional 
measure of security to the system. 

In alternative embodiments, any combination of the above 
mentioned validation/security methods are used. For 
example, the "caller ID" method may be used to determine 
the origin of a call. If the calling number is deemed valid, w 
then Provider Section 10 is prompted by Main Processing 
Section 20 to provide a log-in name and password, 

If the transmission is successful, Main Processing Section 
20 puts the data into a specified MPS Incoming Data Box 
355 and a successful data transmission receipt is transmitted 65 
to Provider Section 10. Main Processing Section 20 simul- 
taneously creates and records a successful data transmission 
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receipt, which is stored in a database within Main Processing 
Section 20, Each successful data transmission receipt has a 
unique transmission tracking number assigned to it. This 
tracking number is generated by Main Processing Section 20 
for audit purposes. In addition to the unique transmission 
tracking number, each successful data transmission receipt 
contains a date and time stamp, the file name, and the file 
size. The cumulative set of successful data transmission 
receipts enable those individuals who service Main Process- 
ing Section 20 to monitor the performance of the system, 
and to serve as a medium for historical/legal purposes. 

In an alternative embodiment, Main Processing Section 
20 generates a successful data transmission receipt created at 
Provider Section 10 location, and which is then sent to Main 
Processing Section 20 and to Data Provider History Box 135 
by default, if no command to the contrary is returned from 
Main Processing Section 20. 

Once data 118 is received by Provider Section 10, Main 
Processing Section 20 stores and archives the data provided 
by Provider Section 10 in it's original, Data Provider's 
Format. Storage media employed by Main Processing Sec- 
tion may include magnetic and non-magnetic storage 
devices including, but not limited to hard disks, tapes, 
magneto-optical disks, compact disks and memory chips. Of 
course, other forms of data storage are known in the art, and 
it will be appreciated by persons of ordinary skill in the art 
in light of the teachings of this invention, such other forms 
of data storage may be readily used. 

FIG. 6A describes one embodiment for carrying out the 
processes that occur at Main Processing Section 20; PrepS- 
erver Software 354 is the specialized operating system of 
Main Processing Section 20 that performs functions includ- 
ing, but not limited to data capture, data translation, data 
forwarding, Subscriber Section 30 billing, error tracking, 
and data and system security. Additionally, PrepServer Soft- 
ware 354 works along side operating systems such as DOS 
(Microsoft Corporation, Redmond, Wash.), Netware (Nov- 
ell, Inc. Ptoyo, Utah), and UNIX to perform functions herein 
described. 

The PrepServer Software 354 begins in step 352. Once 
initiated, PrepServer Software 354 is instanced and 
assigned, in step 353, a set of MPS Incoming Data Boxes 
355 to patrol. 

In one embodiment, PrepServer Software 354 continu- 
ously scans MPS Incoming Data Boxes 355 of each Provider 
Section 10, searching for new data files in step 357. 

In an alternative embodiment, PrepServer Software 354 
scans MPS Incoming Data Boxes 355 of each Provider. 
Section 10 at predefined times. 

In another alternative embodiment, PrepServer Software 
354 scans all of MPS Incoming Data Boxes 355, but the 
scanning is manually initiated. 

In yet another alternative embodiment, PrepServer Soft- 
ware 354 is dormant until it is triggered by a signal announc- 
ing that new data has been successfully received. 

In step 356, PrepServer Software 354 scans its assigned 
MPS Incoming Data Boxes 355, looking for Provider Data 
Files 115 to be processed. Step 357 defines the collection of 
MPS Incoming Data Boxes 355 that PrepServer Software 
354 is assigned to patrol. Step 358 discerns whether a 
Provider Data File 115 was found and is available. If no 
Provider Data File 115 is available, then step 359 is invoked, 
in which PrepServer Software 354 scanning is completed. If 
a Provider Data File 115 was found, and is available, step 
360 is invoked. In this step, PrepServer Software 354 
discerns the identity of Data Provider 113 and determines 
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which Preprocessor 363 is needed, based upon which MPS 
Incoming Data Box contains a Provider Data File 115, or by 
Destination Address 117 residing inside of Provider Data 
File 115. 

Preprocessor Directory 363 warehouses the various spe- 
cialized PreProcesors, thus functioning as a type of database 
that holds actual programs rather than just representational 
data. Once it has been determined which particular Prepro- 
cessor 363 is needed to translate from the particular Provider 
Data Format of the Provider Data File 115 found, Prepro- 
cessor Directory 362 is accesses to retrieve the appropriate 
Pre-Processor 363 in step 361. Next, Work Area 365 is 
blanked or cleared in preparation for use by Preprocessor 
363 in step 364. Step 366 represents data being moved to and 
from Work Area 365 where data processing occurs. Work 
Area 365 is a temporary directory that is dedicated to the 
need for PrepServer Software 354 to have an area of 
information storage in which data can be manipulated. 

In an alternative embodiment, Preprocessor 363 is 
capable of translating similar Midformat files 342. Such a M 
Preprocessor 363 derives it's capabilities by accessing a 
resource database which describes how to translate the given 
MidFormat Files 342. The resource database describes infor- 
mation in MidFormat Files 342 such as the included fields, 
the size of a given field, and the type of data. This results in 
one Preprocessor 363 being used to translate any similar 
MidFormat Files 342 from any provider. In the best case, 
there would be one Preprocessor 363 to translate all Mid- 
format files 368. In addition to Preprocessor 363 and support 
libraries, a graphical editor is used to create and modify the 
resource database used by such a Preprocessor 363. This 
allows Preprocessor 363 systems to be quickly set up to add 
and translate new Midformat files 342. 

Because of the scalability of Main Processing Section 20, 
multiple PrepServer Software 354 programs, as well as 
multiple PrepServer Hosts 78, may be operated simulta- 
neously. 

Data processing involves Preprocessor 363 translating 
Provider Data Files 115 to a MidFormat, storing the resultant 
MidFormat Files 342, counting the number of transactions 
in MidFormat, and finally returning Success Flag 369, or a 
Failure Hag 370 to PrepServer Software 354, indicating 
whether or not Preprocessor 363 successfully translated 
Provider Data File to which it had been assigned. These last 
events occur within step 367 of FIG. 6A. Further details of 45 
one embodiment of Preprocessor 363 function are shown in 
FIG. 6B. 

FIGS. 6B and 6C describe a method and data structures 
used in an embodiment for creating MidFormat File 342 
from a Provider Data File 115. 

In step 301, Preprocessor 363 is selected and sent into 
operation by PrepServer Software 354. 

In step 305, Preprocessor 363 gets Subscriber ID 308 
located in Provider Data File 115 header. This is done by 
looking in a given byte location for a sequence of bytes 
making up Subscriber ID 302, or by finding a attribute-value 
pair and returning the value found. 

In step 310, using Subscriber ID 302, Preprocessor 363 
gets Subscriber Job Number 311 from Subscriber Table 314. 
In one embodiment, Preprocessor 363 accesses Subscriber 
Table 314, a database table or file such as one created in 
Paradox (Borland, Scotts Valley, Calif.) to get Subscriber 
Record 307, then returns Subscriber Job Number 311 from 
that record. 

In step 315, using Subscriber ID 308 and Subscriber Job 
Number 311, a unique filename is generated for MidFormat 
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File 342. In one embodiment, a unique filename is generated 
by using a three letter Subscriber ID as a prefix, and 
appending a five letter job number after first incrementing it. 
For example, if Subscriber ED is "AAA" and the job number 
is "00000", then the unique filename produced would be 
"AAAOOOOl". Note the job number is incremented and 
saved for the next time a unique filename must be generated. 
Also note the job number is using a base-36 notation, whose 
values belong in the set [0-9 A-Z], This means the number 
of unique filenames which can be generated for this one 
Subscriber Section 30 is 36 to the 5th power, i.e. approxi- 
mately 60.4 million filenames. Of course, a wide variety of 
other file naming schemes, such as the many known in the 
art, may also be used. 

In step 320, Preprocessor 363 creates an empty MidFor- 
mat File 342 in Work Area 365, in order to serve as a matrix 
in which translated data is placed. 

In step 325, Preprocessor 363 obtains Subscriber Trans- 
lation Information 312 from Subscriber Table 314. Sub- 
scriber Translation Information 312 describes the format of 
Provider Data File Transactions 302, which collectively 
constitute most of Provider Data File 115, and which Pre- 
Processor 363 translates to MidFormat File Transactions 
304. Subscriber Translation Information 312 includes the 
names, types and sizes of the fields it will be accessing in 
Provider Data File Transaction 302, and serves as an inter- 
pretive guide by which Preprocessor 363 can completely 
read Provider Data File 115. Attribute-value pairs may also 
be used to describe the fields found in Provider Data File 
Transaction 302. 

In step 330, Preprocessor 363 attempts to get a Provider 
Data File Transaction 302 from Provider Data File 115. If it 
finds one, it continues to step 335 to translate the found 
transaction, in which Preprocessor 363 manipulates Pro- 
vider Data File 115 according to the rules specified in 
Preprocessor 363. Such rules may include, but are not 
limited to, instructions for the transposition of specific fields, 
and other known means for accomplishing file format trans- 
lation. If a Provider Data File Transaction 302 is not found, 
Preprocessor 363 assumes the end of Provider Data File 115 
is reached, and proceeds to step 350. 

In step 335, using Subscriber Translation Information 312 
found on Subscriber Table 308, Preprocessor 363 takes a 
Provider Data File Transaction 302 and generates the 
equivalent MidFormat File Transaction 304. In step 340, the 
generated MidFormat File Transaction 304 is written to 
MidFormat File 303. 

Once Preprocessor 363 successfully manipulates the data 
file, the resulting data file is now called MidFormat File 342. 
The data file is called "MidFormat" because is in a standard 
format from which it can be ultimately converted into any 
destination format 

In step 345, a counter keeping track of the number of 
transactions processed so far is incremented. After this is 
done, Preprocessor 363 returns to step 330 and attempts to 
obtain the next Provider Data File Transaction 302. In step 
350, Preprocessor 363 cannot find any more Provider Data 
File Transactions 302 to process, so it records the number of 
transactions it processed in Transactions Table 313, and 
returns to PrepServer Software 354 in step 352. 

Returning to FIG. 6A, in step 371, if Preprocessor 363 
returns Success Flag 369 in step 371, then step 370 is 
invoked. In step 370 PrepServer Software 354 distributes 
MidFormat File 342 from Work Area 363 to the appropriate 
MPS Outgoing Data Boxes 371, using Subscriber Destina- 
tion Address 117 as a guide 371A, 371B and 371C are 



02/24/2004, EAST Version: 1.4.1 



5,608,1 

17 

examples of different Subscriber Outgoing Data Boxes 371, 
each dedicated to a specific file type and Subscriber 33. After 
the distribution occurs, PrepServer Software 354 updates 
Billing and Administrative System 373 with Subscriber 
Transaction Count 374 in step 372. Billing and Administra- 5 
tive System 373 is a database containing a listing of Sub- 
scribers and relevant account information that allows sub- 
scribers to be appropriately billed for their usage of the 
herein described system. This usage count is continually 
updated in step 375. In Step 376, PrepServer Software 354 1Q 
moves Provider Data file 115 from MPS Incoming Data Box 
355 to MPS History Box 377. PrepServer Software 354 has 
then completed it's process. 

If Preprocessor 363 returns Failure Flag 370, however, 
step 378 is invoked, in which PrepServer Software 354 15 
updates Error Log 379 with a report of Preprocessor 363 
Failure flag 370, In step 380, PrepServer Software 354 
moves Provider Data File 115 from MPS Incoming Data 
Box 355 to MPS Failed Data Box 373. PrepServer Software 
354 has then completed it's processing. 2 o 

In step 368, Preprocessor 363 sends a response to PrepS- 
erver Software 354 indicating that either a successful trans- 
lation has occurred or has not occurred. In one embodiment, 
the final task of Preprocessor 363 is to submit a response, 
such as the answer "1" signifying a successful translation or 25 
such as the answer "0" signifying an unsuccessful transla- 
tion. 

In an alternative embodiment, the computer operating 
system, such as DOS, signifies the success or failure of the 
translation. Upon successful completion of Preprocessor, 30 
operating systems such as DOS return a default response of 
the answer "1". This response is then interpreted by PrepS- 
erver Software 354 to perform subsequent events. Upon a 
failure to complete execution of Preprocessor 363, operating 
systems such as DOS return a default response of the answer 35 
"0". This response is then interrupted by PrepServer Soft- 
ware 354 to provide error messages to the administrator of 
PrepServer Software 354. 

In the event that a data file 115 fails to move from MPS 
Incoming Data Box 355, or fails to move from Work Area 40 
365 to MPS Outgoing Data Box 371 the data file is moved 
to the Failed Data Box. The Failed Data Box is an area 
which triggers a user error report and screen display speci- 
fying that a movement of data has occurred and that exami- 
nation is necessary to rectify the error. . 45 

Numerous failures can occur while data processing. These 
events include, but are not limited to failures in hardware, 
software, power supply, and of telecommunication lines. In 
the event that a data translation fails, the data file is moved 5Q 
from Work Area 365 to a Failed Data Box subdirectory. The 
Failed Data Box subdirectory is an area which triggers a user 
error report and/or screen display specifying that a transla- 
tion error has occurred and that examination is necessary to 
rectify the error. The failure is triggered by Preprocessor 363 55 
or by the operating system as previously discussed. 

In step 370 Preprocessor 363 moves MidFormat File 342 
from Work Area 365 to the correct MPS Outgoing Data Box 
371. PrepServer Software 354 selects which MPS Outgoing 
Data Box 371 is appropriate in the manner previously go 
discussed. 

Additionally, PrepServer Software 354 creates a unique 
transaction assigned to each specific MidFormat File 342. 
This transaction contains a unique transaction tracking num- 
ber. This tracking number is generated by PrepServer Soft- 65 
ware 354 for audit purposes. Additionally, this unique trans- 
action contains a date-stamp, time stamp, the file name, and 
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the file size. The cumulative set of successful data transmis- 
sion receipts enables the user of Main Processing Section 20 
to monitor the performance of the system, and to serve as a 
medium for historical/legal purposes. 

The system utilizes numerous internal databases. These 
internal databases store historical and referential data about 
security, data transmission, PrepServer Software 354, Pre- 
processors 363, translations, Providers Sections 20, Sub- 
scriber Sections 30, billing information, data tests later to be 
described, and internal system logs. 

Provider Sections 20 and Subscribers Sections 30 are 
collectively referred to as "customers", and the database that 
contains information about them is called the Customer 
Definition Table (see Table 1). The purpose of this database 
is to store relevant information about the customers such as 
the customer's name, customer's identification, address, etc. 

The database of Incoming Data Boxes 355 and Outgoing 
Data Boxes 371, is referred to as the Mail Box Database. The 
purpose of this database is to store relevant information 
about which customers own the mail boxes, where the mail 
boxes reside, which Preprocessor 363 performs work on the 
data contained in the mail box, etc., as shown, for example, 
in Table 2. From the moment that a data file arrives from 
Provider Section 10, the data file's ultimate destination is 
predetermined— it will go to a single specific Subscriber 
Section 30. 

In one embodiment, PrepServer Software 354 recalls 
from the internal database containing the successful trans- 
mission data receipts which MPS Incoming Data Box 355 
the data file originally arrived in. Each Incoming Data Box 
355 is assigned to only one Subscriber Section 30, to only 
one transaction type, and to only one MPS Outgoing Data 
Box 371 with a specific transaction type. Hence, a Sub- 
scriber Section 30 may have many MPS Outgoing Data 
Boxes 371 assigned to it and each Outgoing Data Box 371 
representing a single specific type of transaction. For 
example, Subscriber X might have one MPS Outgoing Data 
Box 371 assigned to him for holding his cleared bank check 
files, and a MPS Outgoing Data Box 371 for holding his 
payroll data files. Because both boxes are reference to the 
same party, however, they will be correctly transmitted to 
the same, appropriate Subscriber Section 30. 

In an alternative embodiment, PrepServer Software 354 
detects the appropriate destination from MidFormat File 342 
characteristics other than a Subscriber Destination Address 
117. Such characteristics include but are not limited to the 
file name, the file size, the file header, and the file trailer. By 
such cues, PrepServer Software 354, in one embodiment, 
determines the target MPS Outgoing Data Box 371 and 
moves MidFormat File 342 to that specific box. In an 
alternative embodiment, PrepServer Software 354 detects 
from the Provider's 12 log-in name and or log -in password 
the MPS Outgoing Data Box 371 to select Based upon the 
log-in name and or log-in password, PrepServer Software 
354 then selects the corresponding MPS Outgoing Data Box 
371 based upon a database of log-in names and/or log-in 
passwords with corresponding MPS Outgoing Data Boxes 
371, and moves the MidFormat File 342 to the target box. In 
an alternative embodiment, Provider Section 10 specifies 
which Outgoing Data Box 371 to use, and PrepServer 
Software 354 records this information. Based upon this data 
box identity, PrepServer Software 354 looks up the target 
data box and puts MidFormat Hie 342 into the appropriate 
MPS Outgoing Data Box 371. In yet an additional alterna- 
tive embodiment, a combination of these alternatives is used 
to determine the MPS Outgoing Data Box 371. 
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Table 3 shows some aspects of a database entitled Usage- 
Transactions Table for Tracking and Accounting. This data- 
base contains records of transactions, each transaction rep- 
resenting a translation to MidFormat that has been 
performed, when it occurred, when it was transmitted, and 5 
other such pertinent information. 

Another internal database holds Data Transaction receipts 
for each customer. Specifically, each transaction contains 
information such as the number of transactions that have 
been translated, the date and time processed, and the identity l0 
of the Subscriber. The transactions in this database form the 
basis for customer billing purposes as well as for audit and 
legal purposes. 

A database called the Sys_Jog, such as the example 
shown in Table 4, defines the database of transactions for l5 
each warning and error that occurs in Main Processing 
Section 20. For example, all telecommunication links, 
whether coming in or out, are recorded and date stamped, as 
are attempts to access the ComServer Host 76A and Corn- 
Server Software 201 without valid phone numbers, log-in 2 o 
names, and passwords. 

Another database called Batchnum, such as the example 
shown in Table 5, defines the transaction tracking number 
assigned to each data transmission receipt. The purpose of 
this table is store, assign, and increment a unique number 25 
each time a data transmission receipt is sent to a Provider 
Section 10 and Subscriber Section 30. 

Another database contains all data transmission receipts. 
The purpose of this table is to keep a record of all receipts 
for audit and legal purposes. Each transaction is date and 30 
time stamped, has a unique batch number assigned to it, the 
file size transmitted, and a description of whether the trans- 
fer was successful or not. 

Referring again to FIG. 7, in step 405, ComServer Soft- 
ware 201 is started by the user of Main Processing Section 35 
20. 

In step 410, ComServer Software 201 continuously scans 
modems 54 and multiplexers 74 for a Subscriber Section 30. 
In an alternative embodiment, ComServer Software 201 
scans modems 54 and multiplexers 74 for a Subscriber 
Section 30 at predetermined time intervals. In an alternative 
embodiment, ComServer Software 201 scans modems 54 
and multiplexers 74 for a Subscriber Section 30 at the 
command of the Main Processing Section 20 user. 45 

In Step 415, ComServer Software 201 determines 
whether a Subscriber Section 30 is calling Main Processing 
Section 20. 

In Step 420, ComServer Software 201 determines a call is 
not made. 50 

In Step 425, ComServer Software 201 is terminated at 
predefined times. 

In an alternative embodiment, ComServer Software 201 is 
terminated on demand by MPS 20 user. 

In Step 430, ComServer Software 201 activates the Bill- 55 
ing and Administrative System 373 database. This database 
stores the identity and information about all valid Subscriber 
Sections 30, their corresponding passwords and security 
levels, and their use of the system described in this patent 
application. 60 

In Step 435, ComServer Software 201 accesses Billing 
and Administrative System 373 database to lookup and 
determine whether the calling party is a valid Subscriber 
Section 30. 

to 

Step 440 shows an example of a calling party dialing into 
the Main Processing Section 20. 
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In Step 445, ComServer Software 201 determines 
whether to allow the calling party to connect to Main 
Processing Section 20 based upon the security password and 
security level. 

In Step 450, ComServer Software 201 disconnects from 
invalid calling parties. ComServer Software 201 records the 
calling party phone number along with a date-stamp and 
time-stamp in the Billing and Administrative System 373 
database. Finally, ComServer Software 201 prepares to scan 
and detect the next calling party. 

In Step 455, ComServer Software 201 connects to valid 
Subscriber Section 30 and grants Subscriber Section 30 
access to the Main Processing Section 20. ComServer Soft- 
ware 201 then responds to Subscriber Section 30 request to 
transmit the MidFormat File 368. 

In step 460, ComServer Software 201 determines which 
Subscriber Section 30 that MPS Outgoing Data Box 371 
should be used and begins transmitting Midformat File 368 
in Outgoing Data Box 371. 

In Step 470, ComServer Software 201 sends a Data 
Transmission Receipt 402 to Subscriber Section 30. This 
receipts tells Subscriber Section 30 whether Midformat File 
368 transmitted successfully. Finally, ComServer 201 dis- 
connects from Subscriber Section 30 and prepares for the 
next caller. 

This section describes how Main Processing Section 20 
notifies Subscriber Section 30 and Main Processing Section 
20 database that a successful data transmission has occurred. 
Prior to initiating contact with Subscriber Section 30, Main 
Processing Section 20 places data into Outgoing Data Box 
371. A successful data transmission is signaled to Main 
Processing Section 20 by a response produced by the 
modem protocol. Most standard modem protocols, including 
X, Y, and Z modem protocols, have internal error checking 
means that will carry out this task for Main Processing 
Section 20. 

Upon successfully transmitting MidFormat File 342 and 
the completion of the data transmission protocol, Main 
Processing Section 20 moves MidFormat File 342 from 
MPS Outgoing Data Box 371 to a MPS History Box. 

As PrepServer Software 354 moves MidFormat File 342 
from MPS Outgoing Data Box 371 to MPS History Box, a 
successful data transmission receipt is transmitted to Sub- 
scriber Section 30. Main Processing Section 20 simulta- 
neously creates and records a successful data transmission 
receipt stored in Main Processing Section 20 database. Each 
Successful data transmission receipt has a unique transmis- 
sion tracking number assigned to it. This tracking number is 
generated by Main Processing Section 20 for audit purposes. 
In addition to the unique transmission tracking number, each 
successful data transmission receipt contains a date and time 
stamp, the file name, and the file size. The cumulative set of 
successful data transmission receipts enable the user of Main 
Processing Section 20 to monitor the performance of the 
system, and to serve as a medium for historicaiyiegal pur- 
poses. 

In an alternative embodiment, Main Processing Section 
20 generates a successful data transmission receipt which is 
sent to Main Processing Section 20, and to a Subscriber 
Section 30 History Box by default, if no command to the 
contrary is returned from Main Processing Section 20. 

FIG. 8 shows a detail of one embodiment of the processes 
occurring within Block 500 of FIG. 3, primarily, Subscriber 
Section 30 receiving and storing MidFormat Files 368 from 
Main Processing Section 20. In one embodiment, Subscriber 
Section 30 initiates contact with Main Processing Section 20 
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with telecommunications link 21, for example by modem. 
Subsequently, Subscriber Section 30 is identified by Main 
Processing Section 20, and assessed as to whether the link 
is with a valid subscriber. Unless the call is deemed to be 
valid, the downloading of MidFormat Files 342 form Main 5 
Processing Section 20 does not begin. 

In one embodiment, Main Processing Section 20 employs 
the caller identification method. By this caller ID method, 
the telephone number of any party attempting to establish 
connection with Main Processing Section 20 will be l0 
obtained by methods and devices well known in the art The 
number obtained is screened by Main Processing Section 20 
by matching the telephone number of the calling party to a 
list of valid Subscriber Section 30 telephone numbers. This 
valid number list is maintained by a database internal to 15 
Main Processing Section 20 to ensure that the calling party 
is a valid Subscriber Section 30. If the number is not that of 
a valid Subscriber Section 30, Main Processing Section 20 
does not establish a connection, and Main Processing Sec- 
tion 20 time-stamps, date-stamps, and records that invalid 2 o 
phone number. If the number captured, on the other hand, 
represents a valid Subscriber Section 30, Main Processing 
Section 20 allows the transfer of the appropriate MidFormat 
Files 342 to Subscriber Section 30. 

In an alternative embodiment, Main Processing Section 25 
20 prompts Subscriber Section 30 for a valid log-in name 
and/or password. The entry of a log-in name and/or pass- 
word may be automatic or manual on the part of the user of 
Subscriber Section 30. 

In an alternative embodiment, data transmission is initi- 30 
ated by the call of Main Processing Section 20 to Subscriber 
Section 30, rather than vice-versa. 

In another alternative embodiment, a connection between 
Subscriber Section 30 and Main Processing Section 20 will 
be established upon securing access through existing secu- 35 
rity systems such as a Firewall. 

In an alternative embodiment, the "call-back" method is 
used. In this case, Subscriber Section 30 establishes a 
connection with Main Processing Section 20. Main Process- ^ 
ing Section 20 verifies the validity of Subscriber Section 30 
by means such as those described above. Telecommunica- 
tion Link 21 is then disconnected. Next, Main Processing 
Section 20 calls back to, and connects with Subscriber 
Section 30, and then proceeds to transfer the appropriate 
MidFormat Files 342 to Subscriber Section 30. The need for 
a call to be returned by the prospective data source (in this 
case, Main Processing Section 20), provides an additional 
measure of security to the system 

In alternative embodiments, any combination of the above 50 
mentioned validation/security methods are used. For 
example, the "caller ID" method may be used to determine 
the origin of a call. If the calling number is deemed valid, 
then Subscriber Section 30 is prompted by Main Processing 
Section 20 to provide a log-in name and password. 55 

Using a modem, for example, Subscriber Section 30 can 
either directly download MidFormat File 342 from Main 
Processing Section 20, or receive this information using 
electronic mail. Any of a variety of modem protocols may be 
used, such as X, Y, or Z modem protocols. Of course, there 60 
are other non-modem means of electronic data transmission 
known in the art that are also suitable for this purpose. A 
single modem can be used to transmit data to Subscriber 
Sections 30. Alternatively, a multiplexer can be used to 
handle several simultaneous transmissions to multiple Sub- 65 
scriber Sections 30. A multiplexer is a device well known in 
the art, which networks several modems and telephone lines 
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together. Such devices are commonly available. Examples 
include the '"Wildcat BBS IM, MultiPort Multiplexer (Mus- 
tang Software, Bakersfield, Calif.) 

The software used to support the Telecommunication 
Links 21 necessary to transfer Midformat Files 342 from 
Main Processing Section 20 to Subscriber Section 30 may be 
one such as RipTerm (TeleGrafix Communications Inc., 
Huntington Beach, Calif.). A simple user interface that gives 
the necessary instructions to the telecommunications soft- 
ware to carry out the previously described tasks may be 
assembled by well known methods using software such as 
RipPaint (TeleGrafix Communications Inc., Huntington 
Beach, Calif.). 

MidFormat File 342 may be received by Subscriber 
Section 30 using a combination of security techniques, 
including, but not limited to data encryption and security 
measures internally employed by Main Processing Section, 
to be later described. Methods of data encryption are well 
known in the art. Examples of data encryption methods 
include RSA Data Security's (Redwood City, Calif.) soft- 
ware solutions, and the use of the proposed "Clipper" chip 
hardware solution. 

Alternative methods of communication between sepa- 
rately located sections of this system include the use of 
on-line services such as CompuServe, America Online, 
Prodigy, or infrastructures such as the Internet, each with 
their respective electronic mail and file transfer capabilities. 

In another alternative embodiment, non-modem transmis- 
sion means such as ISDN, and Internet IP/FTP transmit the 
data from Main Processing Section 20 to Subscriber Section 
30. 

FIG. 9 represents one embodiment of the functions per- 
formed by Postprocessor 601 at Subscriber Section 30. 
Postprocessor 601 functions include recording the data 
transmission receipt, detecting MidFormat File 342, reading 
MidFormat File 342, translating the data in the file, validat- 
ing the data in the file, appending information onto the data, 
inserting the data into the Subscriber's Application Software 
620, and generating warning and errors displayed via the 
screen and paper reports. 

In one embodiment, the user manually starts the telecom- 
munication download process from within Subscriber's 
Application Software 620 in step 540. Once Midformat File 
342 is successfully is downloaded, the Telecommunication 
Software 542 automatically disconnects, and automatically 
initiates Postprocessor 601. 

In an alternative embodiment, the user manually starts the 
telecommunication download process in Subscriber' s Appli- 
cation Software 620. Once MidFormat Files 342 are suc- 
cessfully downloaded, the user of Subscriber Section 30 
quits telecommunication package and manually starts Post- 
Processor 601. 

In yet an additional embodiment, the user manually starts 
the telecommunication download process as an independent 
process outside of Subscriber's Application Software 620. 
An example of this method is using America Online' s 
telecommunications software and interface to download a 
file previously uploaded to America Online by Main Pro- 
cessing Section 20. Once MidFormat File 342 is success- 
fully downloaded, the user quits the Telecommunication 
Software 542 (in this example, America Online's package) 
and manually starts Postprocessor 601 to perform the tasks 
previously described. 

Step 610 shows Postprocessor 601 recording Data Trans- 
mission Receipt 603. This receipt serves to provide the user 
of Subscriber Section 30 with acknowledgment that Mid- 
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Format File 342 has been either successfully or unsuccess- 
fully downloaded and to let the user of Subscriber Section 30 
know that the telecommunication download processing 
phase is complete. Additionally, Data Transmission Receipt 
603 is stored in Transmission Receipt Database 607 to 
enable the user of subscriber Section 30 to subsequently 
review previous downloads for auditing and accounting 
purposes. 

In step 620, Postprocessor 601 searches for Midformat 
File 342. Postprocessor 601 detects the correct MidFormat 
File 342 by searching for a specific file name and/or looking 
up the specific file name in a specific data directory. 

In step 625, Postprocessor 601 begins performing several 
tasks, starting with reading MidFormat File 342. In step 630, 
Postprocessor 601 subsequently records the data transmis- 
sion receipt, displaying to the user of Subscriber Section 30 
that a successful or unsuccessful data file exists. This 
process also involves discerning and displaying to the user 
of Subscriber Section 30 whether the MidFormat File 342 is 
the correct file, and discerning whether the data inside the 
file is complete and correct by using tests such as check 
sums, algorithms and other such tests, as is known in the art. 

If any single one or a combination of these test results 
indicate that there is a problem with the data set, Postpro- 
cessor 601 halts all tasks. Postprocessor 601 then displays 
and/or print out a WamingflError Report. Additionally, Post- 
Processor 601 suggests appropriate solutions to the prob- 
lems listed in the Warning/Error Report. Each problem that 
can occur in Postprocessor is given a unique warning and 
error number and these warning and error numbers are 
stored in a Postprocessor 601 database along with the related 
suggested remedy (s). Postprocessor 601 provides remedy 
suggestions by looking up the warning/error number asso- 
ciated with each warning or error in the database, and 
displaying or printing the corresponding interpretations and 
suggested remedies. 

In step 630, Postprocessor 601 reads MidFormat File 342 
into memory where it manipulates MidFormat File 342 data 
in order to perform a format translation. The data manipu- 
lation is performed by a set of instructions provided by 
Postprocessor 601 source code. Each unique Postprocessor 
601 has a specific set of manipulation instructions which are 
suited to the type of MidFormat File 342 being translated — 
for example whether it represents cleared bank checks, or 
payroll transactions— and the Destination Format required 
by Subscriber's Application Software 620. Such instructions 
may include format translation methods such as the rear- 
rangement of data fields, the substitution of data fields using 
look up tables, the re-representation of numeric formats, the 
creation of data fields based upon Postprocessor 601 tests, 
the creation of data fields based specified by the user, the 
creation of data fields based upon lookup tables, the creation 
of data fields based upon Subscriber's Application Software 
620, and other widely known data manipulation functions 
known in the art. 

Additionally, Postprocessor 601 places the transactions in 
the format required by Subscriber's Application Software 
620. This format, in any specific case, is generically referred 
to herein as Destination Format. These databases and data- 
base formats include but are not limited to BTrieve, Oracle, 
Sybase, Informix, Platinum, Great Plains, Solomon, Macola, 
Intuit, and other flat file and relational databases. 

In step 635, one or more tests are performed to validate 
the data. One validation test is to compare the total trans- 
actions, dollar amounts, and other specified fields to control 
totals either in MidFormat File 342 or that are derived by 
Postprocessor 601. 
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A second test is to validate each field in a given transac- 
tion against data held within Subscriber's Application Soft- 
ware 620. This audit test helps to ensure that transactions 
and or data fields belong to the particular Subscriber Section 

Another test involves using calculations such as algo- 
rithms. These tests involve specific calculations, such as 
A+B/C, A 2 +B 2 =C 2 , 2A 2 -H4B 2 + the square root of 3C=X, 
etc., that compare a data field or combination of data fields 
in the transaction against specified data in Postprocessor 
601, or against specified data provided by the user of 
Subscriber Section 30, or against specified data from within 
Subscriber's Application Software 620. Another test 
involves Boolean logic routines, such as 'less than", 
"greater than", "greater than or equal to". These routines 
compare a field or combination of fields in the transaction 
against specified data in Postprocessor 601, against specified 
data generated by Postprocessor 601, against specified data 
provided by the user of Subscriber Section 30, or against 
specified data provided by Subscriber's Application Soft- 
ware 620. 

Another test involves statistical data. Postprocessor 601 
generates statistics based upon a single or a combination of 
fields in MidFormat File Transactions 337. Postprocessor 
601 then compares these statistics against specified data in 
Postprocessor 601, or against other specified data generated 
by Postprocessor 601, or against specified data provided by 
the user of Subscriber Section 30, or against specified data 
provided by the Subscriber's Application Software 620. 

Of course, any combination of the above-described Bool- 
ean logic, statistical, and/or calculation/algorithm-based 
methods may be employed. In the event that a warning or an 
error occurs from one or a combination of these tests, the 
warning(s) or errors(s) are displayed and or printed to the 
user subsequent to the insertion of the transactions that are 
valid. 

These statistics can be displayed or printed for the user of 
Subscriber Section 30 for monitoring transactions, data 
fields, or combinations of transactions and data field statis- 
tics. The comparison of these statistics can then be used for 
threshold warnings and errors, historical monitoring, pro- 
jections, and Test Results Report 612, as shown in step 640. 

In step 645, Test Result Database 617 stores the Boolean 
logic and statistical calculations and algorithms employed 
by Postprocessor 601. In step 650, Postprocessor 601 begins 
inserting valid transactions into Subscriber's Application 
Software 620. Any transactions that are not valid are isolated 
into a separate file. The user of Subscriber Section 30 is 
notified of these exceptions in Warning/Error Report 627 
and/or Test result Report 612. The invalid transactions can 
subsequently be reviewed by the user of Subscriber Section 
30 to create, edit, delete, and save the transactions and or 
fields. These tasks may be performed within the transaction 
browsing option of Postprocessor 601. 

In an alternative embodiment, Postprocessor 601 begins 
inserting all valid and invalid transactions into Subscriber's 
Application Software 620. Postprocessor 601 generates a 
Warning/Error Report 627 and/or Test Result Report 612 
notifying the user of Subscriber Section 30 that warnings 
and/or errors have been inserted into Subscriber's Applica- 
tion Software 620. These reports provide the user of Sub- 
scriber Section 30 with a report detailing each transaction 
that requires the user of Subscriber Section 30 to review the 
transaction in Subscriber's Application Software 620 and 
suggest possible solutions, by means previously described. 

In another alternative embodiment, Postprocessor 601 
inserts all valid and invalid transactions into Subscriber's 
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Application Software 620 and does not provide warning 
and/or error reports. 

In yet another alternative embodiment, Postprocessor 601 
inserts only valid transactions into Subscriber's Application 
Software 620 and Postprocessor 601 generates a report of 5 
invalid transactions. 

In all of these embodiments, Postprocessor 601 inserts the 
transactions into the file formats required by Subscriber's 
Application Software 620. 

Once the User of Subscriber Section 30 quits PostPro- 10 
cessor 601 and initiates the Subscriber's Application Soft- 
ware 620, all of the transactions will show up in that 
application. Subscriber Application Software 640 include, 
but are not limited to relational databases, non-relational 
databases, and flat file programs. Examples of these data- 15 
bases include Btrieve, Oracle, Sybase, and XBase. Examples 
of software applications using these databases include Plati- 
num, Great Plains, Macola, Solomon, and Quicken. 

The resultant data may be stored by any mans known in 
the art, including, but not limited to hard disks, tapes, 20 
magneto-optical disks, compact disks, memory chips. Of 
course, other forms of data storage are known in the art, and 
are applicable within the iramework of this invention. 

After Postprocessor 601 has completed all of its tasks, the 
end result is that transactions have been automatically 25 
entered into Subscriber' s Application Software 620 and have 
been verified and validated, as if the user had manually 
reviewed, calculated, verified, looked-up and cross refer- 
enced, and entered the transactions manually. Use of the 
invention has made this process much faster, more accurate, 
and less expensive. 

The following is an example scenario of a Subscriber 
using the invention herein described. In this example, the 
Subscriber is using accounting software such as Platinum 
(Platinum Software, Irvine, Calif.) as the Subscriber's 
Application Software, and the Subscriber wants to automate 
the processes of data transfer, translation, analysis, and entry 
for payroll and bank statement reconciliation. The Sub- 
scriber, in this example has his payroll processed by a 
commercial payroll processing company such as Automated 
Data Processing (ADP) Inc. (Roseland, N.J.). The Sub- 
scriber also uses a bank, such as Bank of America (San 
Francisco, Calif.), for it's general checking account In this 
example, the payroll processing company and the bank 
participate in the use the invention herein described, and 45 
therefore each have a Provider Section 10 as part of their 
in-house computer systems, with which they serve as Data 
Providers 12. 

The process begins when the bank and the payroll pro- 
cessing company each use their respective Provider Section 50 
10 computer systems to generate their Provider Data Files 
115. Examples of Provider Data Files 115 for payroll and 
bank statement reconciliation, are shown in Tables 7 and 8, 
respectively. Once the Provider Data Files 115 have been 
created, the Data Providers each use their respective Pro- 55 
vider Section Telecommunications Software 142 to transmit 
the data files to Main Processing Section 20. 

Once Main Processing Section 20 successfully receives 
the Provider Data Files 115 from the Provider Section 10, 
Main Processing Section 20 performs tasks such as deter- 60 
mining which subscriber the Provider Data File 115 belongs 
to, translates the files into MidFormat Files 342, and per- 
forming subscriber billing tasks. Examples of the MidFor- 
mat Files 342 are shown in Tables 9 and 10. Once these tasks 
have been completed the MidFormat Files 342 containing 65 
the statement information and the payroll information, are 
placed into the proper Outgoing Data Box 371. 
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At this point, the subscriber of our example uses Sub- 
scriber Telecommunication Software 542 to dial into Main 
Processing Section 20, and download the two MidFormat 
Files 342, The subscriber then starts Postprocessor 601 for 
Payroll. This program performs tasks which include vali- 
dating, calculating, translating, importing, and reporting. 
This process is then repeated using Postprocessor 601 for 
bank statement reconciliation. Examples of Destination For- 
mat Files 610 are shown in Tables 11 and 12. 

Payroll data has been automatically entered into the 
accounting software application general ledger, eliminating 
the need for this data to be entered manually. Subsequently, 
the subscriber enters the general ledger module of the 
accounting application software, and prints out an exception 
report. In this example, the exception report flags the sub- 
scriber that a certain employee received and inappropriate 
amount of money in his last paycheck, and that another 
certain employee's salary expense was allocated to a non- 
existent account number. 

Bank statement data has been automatically entered into 
the bank book module of the accounting software applica- 
tion, eliminating the need for this data to be entered manu- 
ally. The subscriber then enters the bank book module of the 
accounting software application and prints out reports to 
examine if any unusual transactions occurred. In this 
example scenario, a check that does not belong to the 
subscriber, and a check amount that does not agree with the 
bank statement amount have been flagged for the subscriber 
to review. 

In sunimary, the invention herein described eliminates 
several manual tasks, and substantially reduces the high 
labor cost associated with these manual tasks. The system is 
unique for several reasons. First, this invention provides for 
data exchange between an unlimited number of Data Pro- 
viders and Subscribers, at a cost several times lower, than 
possible using conventional systems. Second, the system is 
designed to rapidly connect and configure new Data Pro- 
viders and Subscribers, as a opposed to other systems, which 
require months or years to implement. Third, the system 
provides integral means for sophisticated and intelligent data 
analysis. 

In an alternative embodiment, Provider Data File 115 is 
received at Main Processing Section 20 in the form of a 
scanned image, such as via a fax transmission. There, text 
and numeric values are extracted from the fax transmission 
in a manner to be discussed, and then the resultant data is 
processed as a Provider Data File or as a MidFormat file 
according to the methods previously described. Use of mis 
embodiment has the advantage of not requiring an alpha- 
numeric digital (e.g. ASCII) record as a starting point. By 
the method of this embodiment, a subscriber to the system 
of this invention needs only a paper Printed Statement 702 
with relevant data printed on it, for example, a bank state- 
ment, a scanner such as Fax Machine 705 with which to send 
it to Main Processing Section 20, and a Computer 52 with 
Modem 54J to serve as Subscriber Section 30, as previously 
described. 

As previously described herein, Provider Data File 115 
may any type of data file, including a graphics file. It will be 
appreciated that the digital data obtained when a scanner 
scans a printed sheet of paper constitutes one such type of 
Provider Data File. One can also appreciate that a Subscriber 
who has been mailed a paper bank statement effectively 
becomes a Data Provider himself, once he faxes or otherwise 
provides Main Processing Section 20 with this data. In such 
a configuration, the Subscriber is the same party as the Data 
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Provider, since that same party both sends the fax to Main 
Processing Section 20, and receives back processed data. 
This patent application refers to such a client site as Unified 
Provider/Subscriber Section 713. Alternatively, a computer- 
based machine may send an image bit stream, such as a fax 5 
bit stream directly from the computer's memory, without the 
need to scan from a printed sheet of paper. Alternatively, 
United Provider/Subscriber Section 713 may send Main 
Processing Section 20 an alphanumeric file. Although Uni- 
fied Provider/Subscriber Section 713 may originally receive 10 
the paper document or data file from another party (such as 
a bank, in the case of a bank statement), that original source 
has no electronic connection with the system of the inven- 
tion, and hence is not considered to be the Provider in this is 
particular embodiment of the current invention. In yet 
another alternative embodiment, paper statements or data- 
containing digital media such as diskettes or tape can be sent 
to main processing Section 20 by physical means such as 
mail, courier, or the like; and then directly input into the 20 
system such as by scanner or by disc drive or tape drive. 
Subsequently, the data may be processed in the same manner 
as if it were received over a telecommunication line. 

When a paper document such as a bank statement is 25 
transmitted by a conventional fax machine, a graphic file of 
the printed data is being sent. In other words, the data is sent 
by transmitting a pictorial representation of the scanned 
surface's printed and non-printed areas. Generally speaking, 
forms processing systems perform the following steps: 30 
accept an input file in the form of a fax or scanned image of 
a document, identify the type of document represented, align 
the image, locate each field of information, extract each 
field, segment or cut between the characters, perform, char- 35 
acter recognition, such as by OCR (Optical Character Rec- 
ognition) and/or ICR (Intelligent Character Recognition), 
apply outside knowledge ("knowledge engineering") to 
verify the results, producing an interpretation of the docu- 
ment's image in a form such as an ASCII file. Forms 40 
processing software is well known in the art. In U.S. Pat. No. 
5,131,053, Bernzott, et al. describes a system for recognition 
of characters, and for parsing a page to allow for production 
of the output characters in a logical sequence. In The Forms 45 
Processing Paradigm Shift" Imaging Magazine, March 
1995, pp. 84-95, forty-three such forms processing soft- 
ware-based systems are reviewed. Included in this list is the 
software by Teraform (San Jose, Calif.), which will be used 
as the Forms Processing Software 742 in the particular 50 
examples to follow. Also, forms processing systems such as 
GTESS Automated Data Entry System (GTESS Corp., 
Boulder, Colo.), or Teleform (Cardiff Software, Carlsbad, 
Calif.) may be used as Forms Processing Software 742 55 
herein. 

FIG. 10 shows one embodiment of the invention in which 
the provider data file is a fax transmission of a paper 
document sent to Main Processing Section 20 by a sub- 
scriber to the system. At Unified Provider/Subscriber Sec- 60 
tion 713, Printed Statement 702 is placed into Fax Machine 
705, and sent to Main Processing Section 20 via a telecom- 
munication link carrying Fax Bitstream 710 between the fax 
machine and Fax/Modem 780. Once an incoming fax is $5 
identified, the computer(s) at Main Processing Section 20 
capture each incoming fax page as a unique Fax Bitmap 725 
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image file. As each Fax Bitmap 725 image file is captured, 
the resulting image files are put into Fax Queue 715 — an 
incoming fax holding area, such as a hard disk drive 
directory. Meanwhile, Fax PrepServer A 720 continuously 
scans Fax Queue 715 for Fax Bitmap 725 image files. Once 
PrepServer A identifies Fax Bitmap 725 image files in the 
Fax Queue 715, Fax PrepServer A 720 takes the first Fax 
Bitmap 725 image file and processes it through the bit map 
to TIFF Converter 730. Converter730 is in one embodiment, 
a TSR program which converts the format of the fax files to 
a more universally recognized format, such as TIFF (Aldus 
Corporation, Seattle, Wash.). The first page that is processed 
may contain information about the fax transmission such as 
the number of pages transmitted, who the fax transmission 
came from, who the fax transmission is for, and what type 
of data is being transmitted: Subsequent Fax Bitmap 725 
image files may represent pages of actual transactions. One 
by one, each Fax Bitmap 725 image file is delivered by Fax 
PrepServer A 720 to Converter 730, and are processed into 
TIFF Files 735. After format conversion, Fax PrepServer A 
720 creates Fax Reference File 737— a text file containing 
the names of each TIFF file 735 and the directory location 
of TIFF files 735. Finally, Fax PrepServer A 720 moves Fax 
Reference File 737, along with all of the newly created TIFF 
Files 735 to the next holding location — Forms Processing 
Input Queue 749. 

Fax PrepServer B 740 scans Forms Processing Queue 749 
to determine whether any Fax Reference File 737 and TIFF 
Files 735 are present. Once Fax PrepServer B 740 deter- 
mines that these are present, it calls the Forms Processing 
Software 742 to first read the text file and to subsequently 
process each TIFF file. Forms Processing Software 742 
reads the Fax Reference File 737 to determine how many 
TIFF Files 735 it should process for a given job, and any 
special handling or processing instructions. Forms Process- 
ing Software 742 perform the following steps: accepts input 
files in the form of TIFF images of documents, identifies the 
type of document represented (by means such as reading 
identifying information on the image of a cover page which 
precedes the transmission of the actual data, or by the 
recognition of identifying information on the images of 
actual data pages, such as an account number, name, or a 
specific form layout), align the image, locate each field of 
information, extract each field, segment or cut between the 
characters, perform character recognition, such as by OCR 
(Optical Character Recognition) and/or ICR (Intelligent 
Character Recognition), apply outside knowledge ("knowl- 
edge engineering") to verify the results. The resultant output 
file is a alphanumeric text file such as Comma-Delimited 
ASCII File 770, is placed into MPS Incoming Data Box 355, 
and the original TIFF files are placed in Forms History 
Directory 775 for archival and backup purposes. The newly 
created Comma-Delimited ASCII File 770 is similar in 
structure and content to Provider Data Files 115 previously 
described with respect to other embodiments of the current 
invention, and hence may be further processed according to 
the same methods as described with respect to FIGS. 6A, 
6B, 6C, 7, 8, and 9. Alternatively, Forms Processing Soft- 
ware 742 can place its output directly into a designated 
MidFormat, thus skipping one format conversion step in the 
system process. 
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In an example of the invention in use, we will assume that 
Clemco wants their bank statements automatically entered 
into their Platinum accounting module. Having received the 
printed statement in the mail from their bank, Clemco puts 
the document into a fax machine, and sends it in an ordinary 
manner to the telephone number of Main Processing Section 
20. The fax is turned into an MidFormat File 342 according 
to the methods described with respect to FIG. 10. MidFor- 
mat File 342 is then sent back to Clemco by modem, and 
processed into Subscriber Application Software 620 as illus- 
trated in FIGS. 6A, 6B, 6C, 7, 8, and 9. Consequently, 
Clemco now has in their Platinum accounting module the 
data with was formerly available to them only on-a printed 
sheet of paper. Furthermore, the data has been validated. 

In an alternative embodiment, after a file is converted to 
a MidFormat File 342, the file is compressed and added to 
a database in Telecommunications Software 542. While 
Telecommunications Link 21 is active, a program is run to 
send an electronic mail message to the user that the file is 
processed and ready for download. The file is attached to the 
mail message so that when the user reads the message, the 
file is automatically downloaded. 

Data manipulations in the current invention may be 
metaphorically described as '^manufacturing assembly line" 
style. The spirit of this feature of the invention is to move 
"raw data" into place, convert the "raw data" into usable 
data via processing stages, and finally move the "finished 
data" out for subscribers to use. Such an approach is useful 
because of the need to handle various pieces of raw and 
partially processed data with different programs created by, 
or associated with the present invention. The process 
includes an "assembly line" and "robots". The "assembly 
line" are the devices (both hardware and software) that move 
the data from one processing stage to the next processing 
stage. The "robots" are the programs comprising the current 
invention. 

All Main Processing Section 20 functions in this and other 
embodiments of the invention can, if desired, be conve- 
niently carried out on a single telecommunications-capable 
computer, as well as with a task-distributed network. 

MidFormat, Provider Format, or Destination Format files 
may be, in practice, any format desired, including standard 
EDI formats. 
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A portion of the disclosure of this patent contains material 
which is subject to copyright protection. In particular certain 
Of the file formats, including but not limited to the Midfor- 
mat file format, are subject to copyright protection. The 
copyright owner has no objection to the facsimile reproduc- 
tion by anyone of the patent disclosure, asit appears in the 
Patent and Trademark Office patent files or records, but 
otherwise reserves all copyright rights whatsoever. 

The method and apparatus of the present invention are 
described above with reference to specific embodiments. 
Other embodiments will be apparent to those of ordinary 
skill in the art It is therefore not intended that this invention 
be limited except as indicated by the appended claims. 

TABLE 1 



20 



CUSTOMER 



(© 1994 AutoEntry Online, Inc.) 

Master Customer Definition Table 



Customer ID 



Customer Name 

Contact Person 

Address 1 

Address 2 

Oty 

State 

Country 

Zip Code 

Voice Number 

Fax Number 

Credit Card Name 

Credit Card Number 

Credit Card Expir Date 

Credit Card Holder Name 



6 Alphanumeric ♦Drives internal 
AR billing system 
(Platinum AR) 
40 Alphanumeric 
30 Alphanumeric 
30 Alphanumeric 
30 Alphanumeric 
40 Alphanumeric 

2 Alphanumeric 
IS Alphanumeric 
10 Alphanumeric 
10 Alphanumeric 
10 Alphanumeric 
20 Alphanumeric 
20 Alphanumeric 

4 Alphanumeric 
30 Alphanumeric 



TABLE 2 


(© 1994 AutoEntry OnUne, Inc.) 


MAILBOX 


Master Mailbox Definition Table 


Mailbox ID 


11 Alphanumeric * 


Customer ID 


6 Alphanumeric 


File Server 


47 Alphanumeric 


Disk Volume 


15 Alphanumeric 


Directory Path 


80 Alphanumeric 


Box Type 


1 Alphanumeric Source(S) or Target(T) 


PreOrPost 


12 Alphanumeric 


Processor 





TABLE 3 
(© 1994 AutoEntry Online, Inc.) 



USAGE Transactions Table for Tracking and Accounting 



Batch ID 


12 Alphanumeric 




Customer ID 


6 Alphanumeric 




Provider ID 


6 Alphanumeric 




Data Import Date 


6 Date 


NOTE: IN PARADOX, DATE 


Data Import Time 


8 Alphanumeric 


AND NUMERIC FIELDS 


Transmission Status 


20 Alphanumeric 


DO NOT ACTUALLY USE 


Data Transmission Date 


6 Date 


THE FIELD SIZE; 


Data Transmission Time 


8 Numeric 


INCLUDED FOR 


Target Data Module 


2 Alphanumeric 


CONSISTENCY. 


Number of Headers 


8 Numeric 




Number of Line Items 


8 Numeric 


Time (A8) is "HH:MM:SS" 
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TABLE 4 



(© 1994 AutoEntry Online, Inc.) 
SYS JLOG System Log File - Used by PrcpServer and Overlays 



Entry Date 6 Date 

Entry Time 8 Alphanumeric 

Comment 80 Alphanumeric 



♦Time (A8) is M HH:MM:SS n 



TABLE 5 



(© 1994 AutoEntry Online, Inc.) 



BATCHNUM 



Incrementing Batch ID Number- 
Only 1 record and 1 field 



Last Batch Number 



8 Numeric 



TABLE 6 



(<B 1994 AutoEntry Online. Inc.) 
Preprocessor Command-Line Arguments 



Here is a sample usage message put out by the PP, describing 
the arguments it can use. 

ppOl vcr 1.0 ADP Preprocessor for Subscriber Smith Co. 
usage: ppOl (-log logfilel (-verbose] [-report] |-u$ctabs] 
datafile (work dir) 

where: log = name of alternate system logfile 
verbose m output verbose statements 
report = output human readable report 
usetabs = output spreadsheet ready report 
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TABLE 6-continued 



(© 1994 AutoEntry Online, Inc.) 
Preprocessor Command-Line Arguments 



datafile = Raw Transaction File (RTF) to translate 
work dir = Directory to process RTF ia 

Note: 

10 "ppOl" Should be replaced with the name of the PP. 

"ver 1.0" Should be replaced with the appropriate version. 

"ADP" Should be replaced with the actual provider name the PP is designed 

for. 

"Smith Co." Should be replaced with the actual Subscriber name the PP finds 
in the RTF. 
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TABLE 7 



(© 1994 AutoEntry Online, Inc.) 
Example Payroll File Layout from Data Provider 



SxxxxM AR3 1 94032694909 
8xxxx 1021-0001PR03314-O019106664 
8xxxx 1021-0001 PR0331 4+0000000003 
8xxxx 1140-0001PR03314-O000O47028 
8xxxx 11 50-0001 PR03314-0000052000 
8xxxx 1900-O001PR03314-O000349241 



NET PAY 
NET PAY 

DENTAL INSURANCE 
EMPLOYEE LOANS 
EMPLOYEE 
ADVANCE 



TABLE 8 



(e 1994 AutoEntry OnKoe, Inc.) 
30 Example Bank File Layout from Data Provider 

319761,02,02,93,101410103mployee Group Dental,0008 17.00 
319777,02,02,93,10141010,Employee Group Medical,000103.69 
319735,02,02,93,1014101O,Emp]oyce Group WAS,00O152.38 
3 19741,02,02,93,101 41010 > Supplcraental WAS.000092.35 
036565,03,03,93,10211020,Erap!oyer Group Dcntal,000012.00 



TABLE 9 



(© 1994 AutoEntry Online, Inc.) 
Example Payroll Midformat File Layout 



Subj: ADP midformat data 
Date: 94-08-22 23:28:00 EDT 
From: Santa Clara ADP 
To: Clemco 

# Clemco Mid-Format data file 
# 

# The standardized midformat should have the 

# following characteristics: 
# 

# Held Name Field Length 
# 

# Customer Key 10 

# Account Number 32 

# Payroll Date MM/DD/YY 
tt Debit/Credit 5 

# Description 15 

,,"001 V lO21-O00rV03/31/94" n "-"," 191066.64", 4< NET PAY" 

,,"001*7' 1021-OOOrV < 03/31/94"„ 4, +"," 0.03"," NET PAY" 

„"00r," 1140-O00r,"03/31/94V-\ M 470.28'V 4 DENTAL INSURANCE" 

,,"001*7 uso-ooorwinim'v-"," 520.00V employee loans" 

.."OOrV 4 190<>-O001V'03/31/94V-V 3492.41"." EMPLOYEE ADVANCE" 
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TABLE 10 



# Check Transit Number 15 

# Check Amount 15 

M "0Q5V 319761*7-02/02793?,," 10141010"," 817.00"," 
„"005V 319777VO2/02/93 M „" 10141010"," 103.69"," 

M wv 3ims":'ovowy\r 10141010V 152.38**," 

M "005V 3irmi VQ20203V 1 10141010"," 92.35"," 
„"005V 036565", M O3/03/93"„" 10211020"," 12.00*7' 



34 

providing safeguards for ensuring the quality of the 
data delivered to valid data subscribers; 

initiating connection of provider section with main 
processing section in response to receipt of said valid 
communications initiation prompt; 

connecting said provider section with said main pro- 
cessing section and upon being validated as a valid 
provider section, receiving clearance from said main 
processing section to transmit a copy of said provider 
data file to said main processing section; 

reading said provider data file; 

transmitting said provider data files over said commu- 
nications link to said main processing section; and 

detennining whether said provider data file has been 
transmitted successfully and signaling successful 
data transmission to said main processing section; 
and 

(B) receiving, by said main processing section, said 
provider data file from said provider section and storing 
said received data files in said main processing section; 

(C) translating, by said main processing section, said 
stored provider data file by: (i) copying said stored 
provider data file to a work area file within said main 



(© 1994 AutoEntry Online, Inc.) 
Example Bank Midfonnat File Layout 



Subj: ADP midfonnat data 
Date: 944)8-22 23:28:00 EDT 
From: Santa Clara ADP 
Tb: Clemco 

# Clemco Mid-Format data file 
# 

# The standardized midfonnat should have the 

# following characteristics: 
M 

# Field Name Held Length 

# Customer Key 10 

# Check Number 10 

# Check Dale MM/DD/YY 
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TABLE 11 



(© 1994 AutoEntry Online, Inc.) 
Example Payroll Destination File Layout 



1021 M ,"0001";aP* , ,"NET PAY'VTO/SWyXBfl 1/94",*'3767 , V , 3 , V', M 1 91 066.65"." 
1021 V0001 VIPVNET PAY", , '03/31/94 M , ,, 03/3 im^76T .^V/tHO"." 
1140V0W1 VTP^EOTAL INSL^^ 
ll50V<m^r/*ENffIX>YEE LOA^ 

1 900","0001'7TP'\ M EMPLOYEE ADW03/3 1/94V03/3 1/947*3767 V3",V3492.4r, n 
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What is claimed: 

1. In a distributed computer system including a data 
provider section, a main processing section, and a data 
subscriber section, each said section selectably couplable to 
another section by a communications link including com- 
munications control means, a method for translating and 
transferring data from a provider source format to a sub- 
scriber destination format using a priori knowledge of said 
source and destination formats between said data provider 
section and a said data subscriber section, said method 
comprising the steps of: 

(A) transmitting, by said provider section, a particular 
provider data file from said provider section to said 
main processing section via said communications link, 
said transmitting including the steps of: 
monitoring communications from said provider sec- 
tion; 

recognizing receipt of a valid communications initia- 
tion prompt generated by said provider section com- 
munications control means according to predeter- 
mined communications initiation rules, said rules 



processor section, and (ii) converting said work area 
file from the native format of said provider data file to 

50 . a midfonnat file format; 

(D) forming a communications link, by said main pro- 
cessing section, with a particular one of said subscriber 
sections and transmitting said midfonnat file to said 
subscriber section; 

55 (E) receiving, by subscriber section, said midformat file 
from said main processing section and storing said 
received file in storage within said subscriber section; 
and 

60 (F) translating using said selected second-to-third file 
translation procedure, by said subscriber section, said 
midformat file into a subscriber destination format file 
compatible with said preselected subscriber application 
software routine. 
65 2. The method in claim 1, wherein said step (A) of 
transmitting, further includes, prior to said step of monitor- 
ing, the steps of: 
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appending a subscriber destination address to said pro- 
vider data file uniquely representative of a specific 
subscriber that the data in said particular data file is 
intended to ultimately reach; and 

loading said provider data file with said appended desti- 5 
nation address into an outgoing data box associated 
with said provider within said provider section. 

3. The method in claim 2, wherein said step (A) of 
transmitting, further includes, after said step of determining 
whether said provider data file has been transmitted sue- l0 
cessfully and signaling successful data transmission to said 
main processing section, the steps of: 

in response to receipt of said successful data transmission 
signal, moving the original provider data file from said 
outgoing data box to a history data box within storage 15 
means of said provider section; and 

in response to an indication that said data transmission to 
said main processing section was not successful, writ- 
ing an error indication in a provider section error log. 

4. The method in claim 1, wherein said provider data file 20 
format is a digital image data bit stream encoding a printed 
document. 

5. The method in claim 4, wherein said data provider 
section comprises a facsimile machine including an optical 
scanner for generating a graphical image format file of a 
printed document, and wherein said provider file is coramu- 25 
nicated to said main processing section via facsimile trans- 
mission of said graphical image file. 

6. The method in claim 4, wherein said digital image data 
bit stream is generated directly from information stored in 
memory in a digital computer. 30 

7. The method in claim 4, wherein said data provider 
section and said data subscriber section are the same entity, 
and wherein said entity facsimile transmits provider data in 
the form of a scanned printed statement to said main 
processing section and receives a subscriber format file in 35 
return from said main processing section. 

8. The method in claim 4, further comprising the steps of: 
processing said graphic data file using a form processing 

procedure to generate a non-graphical digital data file 
including information extracted from said scanned 40 
graphical data. 

9. The method in claim 4, wherein said form processing 
procedure includes the steps of: 

accepting an input file in the form of a graphical image of 
a document; identifying the type of document repre- 45 
sented from among a plurality of known possible 
document types; aligning the graphical image with 
known document type fields; locating each field of 
information; extracting each field; segmenting between 
the characters in each said field; performing character 50 
recognition; and producing an interpretation of the 
document's image including alphanumeric components 
in digital form. 

10. The method in claim 1, wherein said communication 
channel between said provider section and said main pro- 55 
cessing section comprises physical transportation of the data 
containing media from a location of a provider to a location 

of said main processing section; conversion of said data 
containing media into electronic form; and input of said 
electronic form to said main processing section. 60 

11. The method in claim 10, wherein said data containing 
media is selected from the group consisting of a paper 
statement, a data-containing diskette, a data-containing tape, 
and combinations thereof. 

12. The method in claim 11, wherein said physical com- 65 
muni cations is selected from the group consisting of: mail, 
courier, and combinations thereof 
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13. In a distributed computer system including a data 
provider section, a main processing section., and a data 
subscriber section, each said section selectably couplable to 
another section by a communications link including com- 
munications control means, a method for translating and 
transferring data from a provider source format to a sub- 
scriber destination format using a priori knowledge of said 
source and destination formats between said data provider 
section and a said data subscriber section, said method 
comprising the steps of: 

(A) transmitting, by said provider section, a particular 
provider data file from said provider section to said 
main processing section via said communications link; 

(B) receiving, by said main processing section, said 
provider data file from said provider section and storing 
said received data files in said main processing section, 
said step of receiving including the steps of: 
monitoring a communication link port for messages 

from a calling party requesting a communication 
connection according to predetermined monitoring 
rules and determining whether a provider section is 
calling main processing section requesting a com- 
munication connection; 

determining whether to allow said calling party to 
connect to said main processing section based upon 
pre&tennined security information stored in said 
computer system and security access rules; 

disconnecting from an invalid calling party not satis- 
fying said security access rules; and 

maintaining said communication connection between a 
valid provider section and a valid main processing 
section satisfying said security access rules and 
granting access between said valid provider section 
and said valid main processing section; and 

(C) translating, by said main processing section, said 
stored provider data file by: (i) copying said stored 
provider data file to a work area file within said main 
processor section, and (ii) converting said work area 
file from the native format of said provider data file to 
a midformat file format; 

(D) forming a communications link, by said main pro- 
cessing section, with a particular one of said subscriber 
sections and transmitting said midformat file to said 
subscriber section; 

(E) receiving, by subscriber section, said midformat file 
from said main processing section and storing said 
received file in storage within said subscriber section; 
and 

(F) translating using said selected second-to-third file 
translation procedure, by said subscriber section, said 
midformat file into a subscriber destination format file 
compatible with said preselected subscriber application 
software routine. 

14. The method in claim 13, wherein said step of deter- 
mining whether to allow said calling party to connect within 
step (B), comprises the steps of: 

activating a billing and administrative system database 
storing information regarding all valid providers 
including each provider's respective provider section, 
and corresponding passwords and security levels; and 

accesses said billing and. administrative system database 
to lookup and determine whether the calling party is. a 
valid provider section. 

15. The method in claim 14, wherein said step (B) of 
receiving said provider data file from said provider section 
further comprises, after said step of maintaining said com- 
munication connection, the steps of: 
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responding to a provider section request that said main . 
processing section receive a particular provider data 
file; 

determining which provider incoming data box should be 
used based on predetermined provider criteria and 5 
storing said particular provider data file to said incom- 
ing data box; and 

sending a data transmission receipt to said provider sec- 
tion informing said provider section that said particular 
provider data file transmitted successfully. 10 

16. In a distributed computer system including a data 
provider section, a main processing section, and a data 
subscriber section, each said section selectably couplable to 
another section by a communications link including com- 
munications control means, a method for translating and 15 
transferring data from a provider source format to a sub- 
scriber destination format using a priori knowledge of said 
source and destination formats between said data provider 
section and a said data subscriber section, said method 
comprising the steps of: 20 

(A) transmitting, by said provider section, a particular 
provider data file from said provider section to said 
main processing section via said communications link; 

(B) receiving, by said main processing section, said 
provider data file from said provider section and storing 25 
said received data files in said main processing section; 

(C) translating, by said main processing section, said 
stored provider data file by: (i) copying said stored 
provider data file to a work area file within said main 
processor section, and (ii) converting said work area 30 
file from the native format of said provider data file to 

a midformat file format; 

(D) forming a communications link, by said main pro- 
cessing section, with a particular one of said subscriber 35 
sections and transmitting said midformat file to said 
subscriber section, said step of forming a communica- 
tion link further comprising the steps of: 

scanning a communication link port for a calling party 
attempting to communicate with said main processor ^ 
section according to predetermined rules; 

determining whether to allow calling party to commu- 
nicate with said main processing section based upon 
security information and security access rules; 

disconnecting from a calling party determined to be 45 
invalid based on said security information and secu- 
rity access rules; and 

maintaining said communication connection between a 
valid subscriber section and a valid main processing 
section and granting subscriber section access 5Q 
between said valid subscriber section and said valid 
main processing section; and 

accepting a request for data from said subscriber sec- 
tion and transmitting said requested data in said 
midformat file in response thereto; and 55 

(E) receiving, by subscriber section, said midformat file 
from said main processing section and storing said 
received file in storage within said subscriber section; 
and 

(F) translating using said selected second-to-third file 60 
translation procedure, by said subscriber section, said 
midformat file into a subscriber destination format file 
compatible with said preselected subscriber application 
software routine, 

17, The method in claim 16, wherein said, step (D) of 65 
forming said communications link further comprises, after 
disconnecting from said invalid calling party, the step of 
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recording information concerning the invalid communica- 
tion attempt including a date-stamp and time- stamp in a 
system database. 

18. In a distributed computer system including a data 
provider section, a main processing section, and a data 
subscriber section, each said section selectably couplable to 
another section by a communications link including com- 
munications control means, a method for translating and 
transferring data from a provider source format to a sub- 
scriber destination format using a priori knowledge of said 
source and destination formats between said data provider 
section and a said data subscriber section, said method 
comprising the steps of: 

(A) tjansnutting, by said provider section, a particular 
provider data file from said provider section to said 
main processing section via said communications link; 

(B) receiving, by said main processing section, said 
provider data file from said provider section and storing 
said received data files in said main processing section; 

(C) translating, by said main processing section, said 
stored provider data file by: (i) copying said stored 
provider data file to a work area file within said main 
processor section, and (ii) converting said work area 
file from the native format of said provider data file to 
a midformat file format; 

(D) forming a communications link, by said main pro- 
cessing section, with a particular one of said subscriber 
sections and transmitting said midformat file to said 
subscriber section; 

(E) receiving, by subscriber section, said midformat file 
from said main processing section and storing said 
received file in storage within said subscriber section; 
and 

(F) translating using said selected second-to-third file 
translation procedure, by said subscriber section, said 
midformat file into a subscriber destination format file 
compatible with said preselected subscriber application 
software routine, said step (F) of translating further 
including the steps of: 

selecting a particular post-processor based on prede- 
termined post-processor selection rules including the 
identity of said requesting subscriber section and the 
identity of said preselected application software rou- 
tine; 

searching for a particular midformat file from among 
available midformat files based on rtfedeterrnined 
search criteria; 

reading said midformat file data into a memory of said 
subscriber section; 

reformatting the data from said midformat file into the 
destination format required by subscriber's applica- 
tion software according to predetermined data 
manipulation routines; and 

inserting said data into said subscriber application 
software. 

19. The method in claim 18, further comprising, after the 
step of reformatting said data from said midformat file, the 
steps of: 

testing said reformatted data in the translated destination 
format to validate the data; and if said testing indicates 
that an error has occurred during said reformatting, then 
issuing an error condition message to the user to 
indicate an error condition. 

20. In a computer system including a data provider 
section, a main processing section, and a data subscriber 
section, each said section selectably couplable to another 
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section by a communications channel including communi- 
cations control means, a method for translating and trans- 
ferring data from a native provider source format to a 
subscriber destination format using a priori knowledge of 
said source and destination file formats between said data 5 
provider section and a said data subscriber section, said 
method comprising the steps of: 

(A) transmitting a provider data file, formatted in a 
particular provider data format from among a plurality 

of possible provider data formats, from said provider 10 
section to said main processing section via said com- 
munications channel; 

(B) receiving said provider data file from said provider 
section by said main processing section; 

(C) selecting one particular provider-to-midformat file 15 
format translation procedure, from among a plurality of 
possible provider-to-rnidformat translation procedures, 
for translating said particular provider source format 
into a particular midformat based only on a priori ^ 
knowledge of the identity of said provider and a file 
type characteristic of said particular provider file; 

(D) translating said received provider data file from said 
provider source format to said midformat file using said 
selected one particular provider-to-midformat transla- 25 
tion procedure without iterative trial fitting of said 
provider data into said midformat file; 

(E) communicating said file in said midformat file from 
said main processing section to said subscriber section; 

(F) selecting a particular midformat-to-subscriber format 30 
file translation procedure from among a plurality of 
possible midformat-to-subscriber format file transla- 
tion procedures for translating said particular midfor- 
mat file into a particular subscriber format based only 
on a priori knowledge of the identity of said subscriber 35 
destination and a type characteristics of said subscriber 
file; and 

(G) translating, using said selected midformat-to-sub- 
scriber format file translation procedure, said midfor- 
mat file into said subscriber destination format file 40 
compatible with said preselected subscriber application 
software routine. 

21. The method in claim 20, wherein said step (A) of 
transmitting provider data files from said provider section to 
said main processing section via said communications chan- 45 
nel further comprises the steps of: 
monitoring communications from said provider section; 
recognizing receipt of a valid communications initiation 
prompt generated by said provider section communi- 50 
cations control means according to predetermined com- 
munications initiation rules, said rules providing safe- 
guards for ensuring the quality of the data delivered to 
valid data subscribers; 
initiating connection of provider section with main pro- 55 
cessing section in response to receipt of said valid 
communications initiation prompt; 
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connecting said provider section with said main process- 
ing section and upon being validated as a valid provider 
section, receiving clearance from said main processing 
section to transmit a copy of said provider data file to 
said main processing section; 

reading said provider data files; 

transmitting said provider data files over said communi- 
cations link to said main processing section; and 

signaling successful data transmission to said main pro- 
cessing section. 

22. The method in claim 20, wherein said computer 
system is a distributed computer system. 

23. The method in claim 20, wherein said provider data 
file format is a digital image data bit stream encoding a 
printed document 

24. The method in claim 23, wherein said data provider 
section comprises a facsimile machine including an optical 
scanner for generating a graphical image format file of a 
printed document, and wherein said provider file is commu- 
nicated to said main processing section via facsimile trans- 
mission of said graphical image file. 

25. The method in claim 23, wherein said data provider 
section and said data subscriber section are the same entity, 
and wherein said entity facsimile transmits provider data in 
the form of a scanned printed statement to said main 
processing section and receives a subscriber format file in 
return from said main processing section. 

26. The method in claim 23, wherein said communication 
channel between said provider section and said main pro- 
cessing section comprises physical transportation of the data 
containing media from a location of a provider to a location 
of said main processing section; conversion of said data 
containing media into electronic form; and input of said 
electronic form to said main processing section. 

27. The method in claim 23, further comprising the steps 
of: 

processing said graphic data file using a form processing 
procedure to generate a non-graphical digital data file 
including information extracted from said scanned 
graphical data. 

28. The method in claim 27, wherein said form processing 
procedure includes the steps of: 

accepting an input file in the form of a graphical image of 
a document; identifying the type of document repre- 
sented from among a plurality of known possible 
document types; aligning the graphical image with 
known document type fields; locating each field of 
information; extracting each field; segmenting between 
the characters in each said field; performing character 
recognition; and producing an interpretation of the 
document's image including alphanumeric components 
in digital form. 
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ABSTRACT 



A self diagnosis method and control apparatus for positive 
self diagnosis of equipment having complicatedly interlaced 
mechanical portions. Equipment under diagnosis is divided 
into a plurality of areas under diagnosis, each of which is 
assigned an evaluation variable. Diagnosis is executed in 
units of diagnostic steps classified for each area under 
diagnosis. Based on an execution result, points are allotted 
to the evaluation variable. Based on the evaluation variable, 
or a sum of allotted points, each area under diagnosis is 
diagnosed and a diagnostic result is displayed for self 
diagnosis. Meanwhile, those diagnostic steps which are 
determined invalid by an execution result of another diag- 
nostic step will not be executed. The equipment under 
diagnosis includes those which contain mechanical portions. 

20 Claims, 11 Drawing Sheets 
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IF NO ABNORMAL CONDITION PERSISTS, 
END THE DIAGNOSIS. 



02/24/2004, EAST Version: 1.4.1 



U.S. Patent 



Nov. 21, 1995 



Sheet 6 of 11 



5,469,563 



F I G. 6A 

(START) 



(1) (NORMAL OPERATING STATE) 

(2) SET SELF DIAGNOSTIC ? YES— OBTAIN MODE AND 

j AREA REQUESTS. 

(3) START SELF DIAGNOSIS ? NO — ■ 

(4) MODE /AREA SETTING OK ? NO— 

♦ 

SELF DIAGNOSIS MODE STARTS. 

(5) OBTAIN, FROM MODE AND AREA, THE NUMBER OF 
THE STEP TO BE EXECUTED. 

I IF RESET BY PROCEDURE (18). 



(6) OBTAIN THE NUMBER OF THE STEP TO BE 
EXECUTED NEXT. 

(7) END ? YES— GO TO (*l). 

(8) THE STEP ATTACHED WITH INVALID FLAG ? 

J YES — 

(9) EXCHANGE TAPES ? NO — 

(10) TAPE EXCHANGE IS DISPLAYED. WAIT UNTIL 

THE^ CO RRECT TAPE IS LOADED. 

(I I) EXECUTE THE STEP ACCORDING TO THE CONTENTS 
OF TABLE 2 . 
♦ 

(12) ERROR OCCURRED ? NO — 

(13) INVALID ERROR ? YES— 

(14) FATAL ERROR ? YES —GO TO (*l) . 

(15) MANIPULATE THE GRADE VALUE OF CORRESPONDING 
AREA ACCORDING TO ERROR CONTENTS. 

I 

© 
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'■■ (16) RESULT OF THE LAST STEP VALID ? NO — • 1 

it 

■ (STORE THE RESULT.) 

i 

(17) IF THE RESULT IS NO GOOD, POINTS ARE ADDED TO 
I THE GRADE OF THE CORRESPONDING AREA IN THE 

TABLE OF FIG. 7. IF POINTS HAVE BEEN ALLOTTED' 
! TO OTHER AREAS, THEY ARE ADDED TOO. ' 

NECESSARY INFORMATION IS WRITTEN TO THE 
TABLE OF FIG. 8 . IF THE STEP FLAGGED INVALID 
HAS ALREADY BEEN EXECUTED, POINTS ADDED BY 
THAT EXECUTION ARE SUBTRACTED FROM THE 
AREA. NECESSARY INFORMATION IS WRITTEN TO 
TABLE OF FIG. 10 . 



(18) HARDWARE RESET IS PERFORMED AS REQUIRED. 
♦ 

(6) 
(*l) END 

(20) RESULTS (TABLE 4) ARE DISPLAYED IN THE ORDER 
OF THEIR GREATER NUMBER OF POINTS ALLOTTED. 
PROVIDED THAT, HOWEVER, NO AREA HAVING 
POINTS LESS THAN PREDETERMINED VALUE IS 
DISPLAYED. 

(21) ON THE KEYBOARD, CLEAR THE COLLECTED 
INFORMATION. 

(22) [END] 



FIG. 6 



FIG.6A 



FIG.6B 
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MODE 
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2 ! 
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TOTAL 
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r\r— i>|i nn 
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TOTAL NUMBER 
OF STEPS 
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1 
1 


5 


AREA (II) 
(PIF) 
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3 4 






3 


AREA (12) 
(PR(1 >) 


i 2 






5 6 


4 


AREA (13) 
(PR(2)) 


7 8 






9 10 
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F ' 
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f ' 


[ 1 


f 
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— (*!) 
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STEP 
No. 


(a) 


(b) 


(c) 


1 


0 






2 


1 


0 




3 


1 


1 




4 


1 


0 




5 


0 




3 


6 


1 


1 





















NOT EXECUTED. 
FOUND OK. 
FOUND NO GOOD. 

DETERMINED MEANINGLESS 
FROM THE RESULT OF 
STEP 3. 
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STEP 
No. 


CONTENT DESCRIPTION 
CHARACTER STRING 


EXECUTION 

PROGRAM 

ADDRESS 


POINT 
ALLOTMENT 
PROGRAM 
ADDRESS 


1 


PIF board PIO R/W check 


xxxx 


xxxx 


2 


PR(x) PIO r/w check 


xxxx 


xxxx 


3 


PIF read data check 


xxxx 


xxxx 


4 
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GRADE STEPS a MESSAGES 



AREA 1 1 (PIF) 


45 


1-100,3-0,4-52 


AREA I2(PR(I)) 


0 




AREA I3(PR(2)) 


5 


10-120 








AREA8I (power supply) 


0 




AREA 82 (cooling fan) 


0 




AREA 83 (ma in mother) 


0 




AREA 83 (sub mother) 


0 




AREA9I (EE-all) 






AREA92(PB.all) 


m w» m m 




AREA93(REC-all) 


mm m m m 




AREA 93 (sub mother ) 







(X) 



(Y) 



(Z) 
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FIG. II 



MESSAGE 
No. 


MESSAGE 


1 


PIF board may be defective 


2 


RF-REC block may be defective 


3 


Thread block may be defective 


4 


PB error rate is too high 


5 

• 
* 
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SENSOR No. 


1 


2 


3 


4 


1 


RELIABILITY 






! 1 




1 

1 
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INSTRUCTION 
TO EXECUTE 



DIAGNOSIS EXECUTION 
CONTROL MEANS 



SPECIFY 
DIAGNOSTIC 
STEP FOR AREA 
AND MODE 



Mil 



130 



DIAGNOSIS RESULT 
DISPLAY MEANS 



LIMIT 



j DISPLAY 



. i 



N3I 



200 EQUIPMENT 
UNDER DIAGNOSIS 

100 SELF DIAGNOSIS 
CONTROL 
APPARATUS 
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INVALID STEP 
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METHOD AND CONTROL APPARATUS FOR 
SELF DIAGNOSIS 



BACKGROUND OF THE INVENTION 5 

1. Field of the Invention 

The present invention relates to a method and a control 
apparatus for self diagnosis and, more particularly, to a 
method and a control apparatus for self diagnosis suitable JQ 
for use in such information processing apparatus as a data 
recorder having a mechanical portion. 

2. Description of the Prior Art 

It is known that some information processing, instrumen- 
tation, or control apparatus or systems have a self diagnostic 1 5 
capability. The self diagnostic capability of a data recorder, 
for example, includes an initial test to be performed when 
the data recorder is powered on, error indication, alarming, 
and error data storage in a regular operation, and various 
tests in a maintenance operation, among others. 20 

Self diagnosis as generally referred to points at the 
diagnostic operations to be performed in the regular run of 
the apparatus as mentioned above, with emphasis placed on 
error detection. It sometimes can happen that one of the 
apparatus's functional portions which is used only once in a 25 
long while, one year for example, is found defective just 
before use. With a conventional data recorder, for example, 
it is a general practice to provide no capability of checking 
the entire recorder system including its infrequently used 
functional portion for a failure or no dedicated self diag- 30 
nostic mode. However, in the field of instrumentation, some 
of apparatus including an oscilloscope are beginning to 
employ the capability for self-diagnosing their electric or 
electronic circuitry. 

However, a limitation with the above-mentioned practice 35 
as performed on some instruments is that self diagnosis is 
adapted to apply only to electric or electronic portions of 
each instrument Therefore, the practice cannot apply to any 
apparatus that contain mechanical portions to be subjected to 
self diagnosis. Such apparatus include a data recorder com- 40 
prising a video tape recorder, for example. 

Unlike an electric or electronic circuit, a mechanical 
portion of an apparatus cannot be definitely defined in terms 
of input and output With the electric or electronic circuit, it 
is general practice to enter a test signal in it and observe a 
resultant output for diagnosis. Mechanically, it is not that 
simple; diagnosis must often be performed on multiple 
complicatedly interlaced portions. 

At a laboratory level, a troubleshooting expert system is 50 
under development for inferring from a symptom a failing 
location based on an artificial intelligence (AI) approach. 
Implementing such expert system requires the use of a 
powerful computer system such as a workstatioa Such 
implementation is unrealistic in terms of cost for the present 55 
invention which intends to incorporate the self diagnostic 
capability in an apparatus. In addition, the construction of an 
expert system requires a large-scale database on which 
inference must be made from a symptom as wisely as a 
human expert. However, it is often difficult to prepare and 
install such a database on an apparatus under fabrication in 
which a self diagnostic capability is incorporated. 

Thus, for the self diagnosis of such apparatus as a data 
recorder, a system must be constructed which, still support- 
ing a conventional diagnostic capability for error detection, 65 
provides a positive troubleshooting capability such as a 
dedicated self diagnostic mode. Further, the above-men- 
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tioned diagnostic system must be able to cope with such a 
complicated symptomatic situation for diagnosing a 
mechanical portion of the apparatus as that, while checking 
portion A, an abnormal condition has been unexpectedly 
detected in portion B. It is also desirable for the built-in 
diagnostic system to be implemented by a simple approach 
rather than complicated one typically supported by AI. 

OBJECTS AND SUMMARY OF THE 
INVENTION 

It is therefore an object of the present invention to provide 
a simple self diagnostic method which can positively self- 
diagnose apparatus having complicatedly interlaced 
mechanical portions, and a controller for implementing the 
self diagnostic method. 

In carrying out the invention and according to one aspect 
thereof, there is provided a self diagnostic method*compris- 
ing the steps of dividing an apparatus under diagnosis into 
two or more areas subject to diagnosis, providing each of the 
areas with an evaluation variable, performing diagnosis in 
units of diagnostic, steps classified by the area, allotting 
points to the evaluation variable of each area under diagno- 
sis associated with the executed diagnostic step according to 
an execution result, and diagnosing each area based on a 
value of the evaluation variable obtained by adding up the 
allotted points. 

When executing a diagnostic operation, it is arranged so 
that no step determined invalid by an execution result of 
another diagnostic step will be executed and an apparatus 
under diagnosis includes apparatus having a mechanical 
portion. 

In carrying out the invention and according to another 
aspect thereof, there is provided a controller 100 as sche- 
matically shown in FIG. 13 comprising diagnosis execution 
control means 110, execution result processing means 120, 
and diagnostic result display means 130, wherein diagnosis 
is performed on a specified area 201 of an apparatus under 
diagnosis divided into multiple areas under diagnosis each 
provided with an evaluation variable, and a diagnostic result 
is determined upon receiving an execution result. Actually, 
as shown in FIG. 13, there is provided, between the con- 
troller 100 and the specified area 201, diagnosis executing 
means for executing diagnosis based on an instruction given 
by the diagnosis execution control means 110 and detecting 
the execution result to send it to the execution result pro- 
cessing means 120. However, the description of this diag- 
nosis executing means is omitted herein because its specific 
configuration and implementation technique do not matter in 
carrying out the present invention. 

The diagnosis execution means 110 has a diagnostic step 
specification capability 111 and executes diagnosis by speci- 
fying a diagnostic step for each area of the apparatus under 
diagnosis 200 and, further, for each diagnostic mode. In 
execution, it is arranged so that a determination by an invalid 
step decision capability 122 in the execution result process- 
ing means 120 is referenced not to execute diagnostic step 
determined invalid by an execution result of another step. 
The invalid step includes those steps which are determined 
invalid by sensor reliability data 123 obtained from the 
execution result of each step carried out by the execution 
result processing means 120 for example. 

The execution result processing means 120 has an evalu- 
ation variable point allotting capability 121 to allot points to 
the evaluation variable of an associated area under diagnosis 
based on the execution result of each step and store a 
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diagnostic result consisting of and integrated value of evalu- 
ation variables (124). In this operation, if a step determined 
invalid by the decision of the invalid step decision capability 
122 has already been executed, the evaluation variable point 
allotting capability 121 subtracts the allotted points from the 5 
associated area under diagnosis. 

The diagnostic result display means 130 displays the 
diagnostic result obtained by the execution result processing 
means 120, starting with an area having a greatest evaluation 
variable. It also has display limit capability 131 for display- ™ 
ing only areas having evaluation variables above a certain 
level which can be varied. 



BRIEF DESCRIPTION OF THE DRAWINGS 15 

FIG. 1 is a block diagram illustrating an entire configu- 
ration of the data recorder according to the present inven- 
tion; 

FIG. 2 is a block diagram illustrating an internal configu- 20 
ration of a CPU board 10 of FIG. 1; 

FIG. 3 illustrates positions of self diagnostic modes in the 
present invention; 

FIG. 4 illustrates an example of how an apparatus under 
diagnosis is divided into areas under diagnosis; 25 

FIG. 5 illustrates how to operate self diagnostic modes; 

FIG. 6-B is an overall flowchart illustrating self diagnos- 
tic mode operations; 

FIG. 7 is a table for determining, from modes and areas 30 
under diagnosis, which diagnostic step is to be executed; 

FIG. 8 is a table in which an execution result of each 
diagnostic step is entered; 

FIG. 9 is a table for determining an address of a diagnostic 
step execution program and an address of a point allotment 35 
calculation program from an internal diagnostic step num- 
ber, 

FIG. 10 is a table in which a grade for each area under 
diagnosis is stored; 

FIG. 11 is a table from which a message is obtained 
according to a message number; 

FIG. 12 is a table for managing sensor output reliability; 
and; 

FIG. 13 is a block diagram schematically illustrating the 45 
self diagnosis controller according to the present invention. 
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A self diagnosis method and its controller practiced as a 
preferred embodiment of this invention as applied to a data 
recorder will be described in detail by way of example with 
reference to the accompanying drawings. 55 

FIG. 1 is the block diagram illustrating the entire con- 
figuration of the data recorder practiced as the preferred 
embodiment of this in vention. In the figure, each block does 
not indicate an actual board configuration; it indicates a 
functional block for self diagnosis, or an area under diag- go 
nosis. 

Reference numeral 1 indicates data input/output interface 
which provides synchronization in data between a digital 
signal processor 2 and data I/O 20 and 21 of the data 
recorder. The digital signal processor 2 performs concurrent 65 
processing in four units for example to increase processing 
speed. 



Digital data 20 entered is fed through the data input/ 
output interface 1 to the digital signal processor 2 to be 
added with an error correction code. A resultant signal is fed 
to an RF-REC (record) system 3 to be recording-compen- 
sated for recording by a rotary head 4. In reproduction, this 
operational flow is reversed; however, instead of the RF- 
REC 3, an RF-PB (playback) system 5 is used. 

A CPU board 10 is a CPU functional portion which 
controls the data recorder in its entirety. An outside remote 
control signal 24 including a self diagnosis start instruction 
and an inquiry for a diagnostic result is entered in the CPU 
board 10 through an interface board 25. A CP 26 is a control 
panel consisting of a keyboard and a display. 

A mechanical sensor 12 represents all sensors installed in 
a tape travel system and a cassette compartment Many of 
these sensors are optical sensors based on pairs of a light 
emitting diodes and phototransistors. A signal coming from 
the sensor 12 is processed by the CPU board 10 to be fed to 
a motor driver 11 as a control signal, driving motors and 
plungers for operating mechanical portions 13 through 19 of 
the tape travel system and the like shown. 

FIG. 2 is the block diagram illustrating an internal con- 
figuration of the CPU board 10! It contains a main CPU 34 
and three sub CPUs; IF CPU 31 for input/output control, PR 
CPU 32 for signal processing control, and SV CPU 33 for 
driver control. Controlled by the main CPU 34, each sub 
CPU in turn controls a corresponding portion to perform a 
data recorder operation. 

The main CPU 34 also executes a self diagnostic 
sequence and contains a self diagnosis controller 38 for that 
purpose. The main CPU 34 is also provided with a storage 
unit 36 for storing a self diagnostic result and a data recorder 
state to be referenced before starting self diagnosis, a backup 
power supply for the storage unit 36, a reset line controller 
41 for hardware-resetting the main CPU itself upon termi- 
nation of the self diagnosis, and a power-on reset circuit 42 
for controlling a reset operation at power-on. 

In what follows, the self diagnosis method according to 
the invention and capabilities necessary for implementing it 
will be described. 

First, the position of the self diagnosis mode according to 
the invention is described. As shown in FIG. 3 and as 
described above, the data recorder is provided with various 
self diagnostic capabilities including an initial test, a regular 
operation diagnostic capability, a test mode, and the self 
diagnosis mode positioned as a dedicated self diagnostic 
mode. The dedicated self diagnostic mode as referred to 
herein is a capability to be intentionally activated for check- 
ing the data recorder for any abnormal conditions. For 
example, this mode is activated, upon switching on the data 
recorder for starting a task, to check the data recorder for any 
trouble or troubleshoot the data recorder when it is found 
malfunctioning. Once in the self diagnostic mode, no regular 
operations including data recording/reproducing can be per- 
formed. 

In the self diagnostic mode, the data recorder is divided 
into multiple areas to be subjected to diagnosis (FIG. 4). The 
self diagnostic mode comprises following four modes which 
respectively cover the areas under diagnosis. In mode 1, 
diagnosis is performed with no tape cassette loaded as with 
an independent reel rotational test. In mode 2, diagnosis is 
performed with an electric system calibration tape loaded as 
with a reproduction of a test signal tape. In mode 3, 
diagnosis is performed with a mechanical calibration tape 
loaded as with a tracking test and a head position control 
test. In mode 4, diagnosis is performed with a blank tape 
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loaded to check whether recording is made normally or not 
One or more diagnostic steps (FIG. 9) are allocated as 
required to each area to be diagnosed in each mode and for 
execution: 

It should be noted that the present embodiment can also 5 
be constituted so that self diagnosis is performed while a 
regular operation such as data recording/reproducing opera- 
tion is in progress. 

Now, referring to FIG. 4, the data recorder is divided into 
areas under diagnosis by way of example. To be specific, the 10 
data recorder is divided into seven divisions of a signal 
processing system, an audio signal processing system, a 
control system, a tape travel system, a tape loading system, 
a miscellaneous system, and an overall system. Each divi- 
sion is further divided into multiple functional blocks or 15 
areas suitable for particular diagnoses. Each area under 
diagnosis is assigned with an area number. 

It should be noted that the areas in the miscellaneous 
division having area numbers on the order of 80 cannot be 
tested alone and the areas in the overall division having area 20 
numbers on the order of 90 have no specific object to be 
diagnosed. With the areas having numbers on the order of 
90, the data recorder is operated in the same manner as a 
regular operation to make an overall diagnosis based on 
status variables such as voltages and on errors detected. 25 

Operations of the self diagnostic mode and an operational 
flow of diagnosis will be described as follows. FIG. 5 
indicates how to operate the self diagnostic mode, in which 
the mode is executed following procedures (1) through (8). 
In procedure (4), a self diagnosis starts. In procedure (5), 30 
diagnostic tapes are exchanged for changing modes as 
instructed by a diagnostic program halfway in its execution. 
FIG. 6 is an overall flow of the self diagnosis indicating the 
self diagnostic operations. In what follows, these self diag- 
nostic operations will be described by referring to the overall 35 
flow. 

First, in procedures (1) and (2), preparations necessary for 
carrying out the self diagnosis are made and desired self 
diagnostic mode and area under diagnosis are entered 
through the control panel or a remote control device. At this 
stage, the entered mode and area are only stored in the 
storage unit and therefore the mode is not yet active. When 
the self diagnostic mode is activated according to procedure 
(4) shown in FIG. 5, the self diagnosis starts following 
procedures (3) through (5) shown in FIG. 6. 

Each diagnostic step, in procedure (6), obtains the number 
of a step to be executed next from a current setting by 
referring to ROM data in which diagnostic steps to be 
executed for each mode have been set for each area as shown 
in FIG. 7. Meanwhile, in procedure (8), contents of RAM in 
which execution results of diagnostic steps are stored as 
shown in FIG. 8 are referred to so that, if a specific 
diagnostic step is found to have already been executed, the 
step will not be executed, or if a diagnostic step to be 55 
executed next based on the result of another diagnostic step 
is found invalid, the step will not be executed, thereby 
passing control to a next diagnostic step. 

Especially, if the output of a sensor is found unreliable by 
the result of a diagnostic step for example, the execution $o 
results of the diagnostic steps associated with the sensor 
output will subsequently be handled as being unreliable. 
Consequently, a table listing the reliability data of each 
sensor is prepared beforehand as shown in FIG. 12. The 
. table is referred to every time a diagnostic step is to be 55 
executed to determine whether the step is valid or invalid. 

When changing a diagnostic mode to another, if a diag- 
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nostic tape need be changed to another, a current tape is 
ejected and a required tape is inserted, a tape exchange event 
is displayed, and the operational flow is held until the tape 
has been fully loaded as in procedures (9) and (10). Each 
step is executed by obtaining an address of a program to be 
executed from its step number based on the ROM data which 
specifies the preset execution contents of each step as shown 
in FIG. 9. 

If a so-called system error occurs during execution of a 
diagnostic step, the error will be handled as follows in 
procedures (12) through (15). The system error is one of the 
following four types: (1) an error whose occurrence is self 
evident from the nature of self diagnosis and which may be 
ignored; (2) an error whose occurrence is expected and its 
presence or absence is positively used for self diagnosis; (3) 
an unexpected error which is useful for self diagnosis and 
allows it to proceed; and (4) an unexpected error which does 
not allow self diagnosis to proceed. 

This error handling is performed in each diagnostic step, 
in which a type of detected error is determined to perform 
necessary processing accordingly. That is, the error of type 
(1) mentioned above is ignored in procedure (13), the error 
of type (4) causes the diagnosis to terminate in procedure 
(14), and the errors of types (2) and (3) add up a grade value 
of an suspected area under diagnosis depending on their 
contents in procedure (15). The grade (or an evaluation 
value, also called an evaluation variable herein) as used 
herein indicates a degree of failure in an associated area 
under diagnosis. Its value is stored for each area under 
diagnosis and may be 0 to 255. This value increments in 
units of 1 to 10 depending on an execution result of each 
step. As this value increases, it is more probable that the area 
under diagnosis is failing. 

When a diagnostic step has terminated in procedure (17), 
the grade value for an area under diagnosis associated with 
that diagnostic step is manipulated; that is, point allotment 
is performed. Points are allotted by a point allotting program 
preset for each diagnostic step. As shown in FIG. 9, an 
address of each point allotting program can be referenced in 
ROM which relates a step number with a diagnosis execu- 
tion program. For example, if executing a diagnostic step to 
test area 22 results in a no good condition, the grade of the 
area 22 is increased by 30 points. If, at this time, area 23 is 
also suspicious, its grade is increased by 20 points for 
example. 

The grade value thus allotted to the area under diagnosis 
is stored in an execution result table (FIG. 10) to be 
described, along with information on the diagnostic step 
executed and diagnostic message. At the same time, whether 
a diagnostic step has been executed or not and, if executed, 
its result are entered in the table of FIG. 9 for each diagnostic 
step. If the execution result indicates that execution of 
another diagnostic step is meaningless, that step is flagged 
invalid. If the diagnostic step having an invalid flag has 
already been executed, it means that its execution will be 
meaningless, thus requiring to subtract the points allotted to 
the associated area from its grade value. 

Some diagnostic steps forcibly change a state in the data 
recorder for testing. Once changed, it is often difficult to 
restore the original state even if the state is in memory. 
Therefore, if this happens, a hardware reset operation is 
executed in procedure (18). When specified diagnostic steps 
have all been executed or if it is determined that a fatal error 
detected in procedure (14) has made impossible the con- 
tinuation of the diagnosis, the diagnosis is terminated (refer 
to (*1) in FIG. 6). 
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The diagnostic result is stored in the RAM as a grade 
value for each area under diagnosis as shown in FIG. 10; that 
is, points to be allotted as results of the execution of 
diagnostic steps are added up in the RAM. At the same time, 
a number of a diagnostic step determined failing and an 
associated diagnostic message are stored (steps & mes- 
sages). For example, as shown in FIG. 11, all messages 
stored in the ROM beforehand are assigned with numbers 
which are stored in the RAM of FIG. 10. In FIG. 10, "1-100" 
indicates that step 1 is no good and message 100 must be 
referred to, "3-0" indicates that step 3 is no good and there 
is no message to be referred to, and so on. 

Now, when the diagnosis has been completed, the result 
is displayed on the control panel starting with an area under 
diagnosis having a highest grade value, in a form "area xx 
is suspicious of failing," in procedure (20). In addition to this 
message, a special message informing a service engineer of 
the reason of failure determination may be displayed for 
each diagnostic step, for example. 

It should be noted here that, as a general rule, no area 20 
under diagnosis having less than 16 points will be displayed. 
This is because, if areas under diagnosis slightly suspicious 
of failing are displayed in large quantities, practicality of the 
self diagnosis would be lost However, the grade or the 
number of points may be lowered from 16 if a service 25 
engineer for example requires more detail failure informa- 
tion. 

If an attempt is made to execute a test of the same mode 
twice, it is judged that a retry of the test is requested, 
automatically erasing previous data. The previous data may 30 
also be manually erased by an operator. 

Data structures, or tables, to be referred to during execu- 
tion of the above-mentioned diagnostic program will be 
described as follows. These tables contain two types of data; 
predefined data stored in the ROM and data stored in the 35 
RAM as a result of diagnostic execution. 

A table of FIG. 7 is used to determine which step is to be 
executed based on a mode and an area under diagnosis 
specified on the control panel. This table is written in the 
ROM of the main CPU 34 beforehand. Each diagnostic step 
is represented in an internal step number uniquely set in the 
data recorder. In the table, a number or numbers indicated 
for each area under diagnosis are step numbers. For 
example, when all steps of area 11 are be checked, steps 1, 
3, and 4 are executed (*1); when all steps of mode 1 are to 
be checked, steps 1, 2, 7, and 8 are executed (*2). 

FIG. 8 is a table in which an execution result of each 
diagnostic step is entered. This table is created in the RAM 
of the main CPU 34. Entries in this table include, for each 
diagnostic step, whether the step has been executed or not, 
a result of execution, and whether the result is invalid or 
valid. In the table, (a) indicates whether the step has been 
executed or not and is 1 if executed; (b) indicates the 
execution result and is 0 if found good; and (c) indicates that 5S 
the execution result of the step is found invalid by another 
step, and is the number of the invalid step. . 

FIG. 9 is a table for obtaining an address of a step 
execution program from the internal step number and an 
address of a grade calculation-program from a step execution 60 
result. This table is also written in the ROM beforehand. In. 
the table, "Execution program address" column contains a 
start address of an execution program corresponding to a 
specified diagnostic step and "Point allotment program 
address" column contains an address of the point allotment 65 
program for recalculating the grade of the diagnostic step 
from a result of a subsequent diagnostic step. "Content 
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description character string" column contains information to 
be used when displaying the content of the specified diag- 
nostic step on the control panel. 

FIG. 10 is a table to store a grade for each area under 
diagnosis and is stored in the RAM. In addition to the grade, 
this table stores an internal number of a diagnostic step 
which manipulated the grade and an internal number of a 
message given by the step. In the figure, (X) indicates an 
area under diagnosis for which a program is executed as a 
main target; (Y) indicates an area under diagnosis circum- 
stantially suspected of failure from a program execution 
result; and (Z) indicates an area under diagnosis for which 
an overall diagnosis is performed without specifying a 
particular location. It should be noted that the (Z) area under 
diagnosis indicates no particular area under diagnosis and 
therefore has no grade value. "Steps & messages" column 
contains the number of a failed step and a storage number 
(refer to FIG. 11) of an associated message. For example, 
"1-100" means that step 1 is no good and message number 
100 must be referred to for description; "3-0" means mat 
step 3 is no good and there is no corresponding message. 

FIG. 11 is a table for obtaining a message from a message 
number and is also stored in the ROM beforehand. 

FIG. 12 is a table for managing sensor output reliability. 
If a result of a diagnostic step indicates that an output of a 
sensor is not reliable, reliability "1" is recorded for the 
sensor. This table is referenced by each diagnostic step to 
determine whether its execution result is valid or invalid. 

As described and according to the invention, actions 
necessary for self diagnosis are taken automatically in 
general, realizing faster and more accurate self diagnosis 
than prior-art techniques. A self diagnosis is performed by 
selecting from multiple diagnostic steps necessary ones. 
More steps executed will result in a more accurate result. If 
required, only a minimal number of steps may be executed 
for a meaningful result 

If an execution result of each diagnostic step indicates two 
or more suspicious areas under diagnosis, the result can be 
used for evaluating such areas by manipulating their grade 
values. 

If an error has been detected during the execution of a 
diagnosis, manipulating the grade values of multiple asso- 
ciated areas under diagnosis allows to positively use the 
error for the diagnosis. 

Further, a failure which cannot be located by a single test 
can be checked by using circumstantial evidence obtained 
by other diagnostic steps without resorting to complex 
inference. In addition, introduction of grade values for 
evaluation allows to use a test which puts out a vague result. 
While the preferred embodiment of the invention has been 
described using specific terms, such description is for illus- 
trative purpose only, and it is to be understood that changes 
and variations may be made without departing from the 
spirit or scope of the appended claims. 

What is claimed is: 

1. A method of self diagnosing an apparatus having a 
plurality of functional areas, the method comprising the 
steps of: 

performing a plurality of diagnostic steps on one of said 
functional areas of said apparatus, said one functional 
area having a grade value representing its functional 
operativeness, each of said plurality of diagnostic steps 
producing a respective diagnostic result; 

allocating a respective point value to each said respective 
diagnostic result; and 

varying said grade value of said one functional area by 
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said respective point value of each said respective 
diagnostic result. 

2. The method of claim 1, wherein the step of performing 
a plurality of diagnostic steps includes the steps of: 

storing validity data for each of said diagnostic steps 5 
based upon diagnostic results of previously performed 
diagnostic steps; 

determining whether a respective diagnostic step to be 
performed is a valid step based upon the stored validity 
data; io 

performing said respective diagnostic step if it is deter- 
mined to be a valid step; 

determining whether other ones of said diagnostic steps 
are invalid steps based upon the produced diagnostic 
result of said performed diagnostic step; and 15 

altering said stored validity data to indicate the invalidity 
of said other ones of said diagnostic steps that are 
determined to be invalid. 

3. The method of claim 2, wherein the step of performing 

a plurality of diagnostic steps further includes the step of 20 
adjusting said grade value in accordance with said point 
values of said diagnostic results of previously performed 
diagnostic steps that are determined to be invalid steps so as 
to nullify previous affects on said grade value by diagnostic 
steps that are determined to be invalid 25 

4. The method of claim 3, wherein the step of varying said 
grade value is carried out by increasing said grade value by 
said point value of said diagnostic result of each said 
performed diagnostic step; and said step of adjusting said 
grade value is carried out by reducing said grade value by 30 
said point value of said diagnostic result of each said 
previously performed diagnostic step that is determined to 
be an invalid step. 

5. The method of claim 1, wherein said diagnostic steps 
are performed on a plurality of functional areas of said 35 
apparatus, each of said functional areas having a respective 
grade value representing a functional operativeness of said 
respective functional area. 

6. The method of claim 5, further comprising the step of 
displaying said functional areas in order of decreasing grade 40 
values. 

7. The method of claim 5, further comprising the step of 
displaying said functional areas having respective grade 
values greater than a predetermined value. 

8. The method of claim 1, wherein the step of allocating 4 * 
a respective point value is carried out by retrieving from a 
memory a value corresponding to said respective result for 
said respective diagnostic step and assigning the retrieved 
value as said respective point value. 

9. A diagnosis system for diagnosing an apparatus having 5 0 
a plurality of functional areas, the diagnosis system com- 
prising: 

means for performing a plurality of diagnostic steps on 
one of said functional areas of said apparatus under 
diagnosis, said one functional area having a grade value 55 
representing its functional operativeness, each of said 
plurality of diagnostic steps producing a respective 
diagnostic result; 

means forallocating a respective point value to each said 
respective diagnostic result; and 

means for varying said grade value of said one functional 
area by said respective point value of each said respec- 
tive diagnostic result 

10. The diagnosis system of claim 9, wherein said means $ 5 
for performing a plurality of diagnostic steps includes: 

means for storing validity data for each of said diagnostic 
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steps based upon diagnostic results of previously per- 
formed diagnostic steps; 
means for determining whether a respective diagnostic 
step to be performed is a valid step based upon the 
stored validity data; 

means for performing said respective diagnostic step if it 
is determined to be a valid step; 

means for determining whether other ones of said diag- 
nostic steps are invalid steps based upon the produced 
diagnostic result of said performed diagnostic step; and 

means for altering said stored validity data to indicate the 
invalidity of said other ones of said diagnostic steps 
that are determined to be invalid. 

11. The diagnosis system of claim 10, wherein said means 
for performing a plurality of diagnostic steps further 
includes means for adjusting said grade value in accordance 
with said point values of said diagnostic results of previ- 
ously performed diagnostic steps that are determined to be 
invalid steps so as to nullify previous affects on said grade 
value by diagnostic steps that are determined to be invalid. 

12. The diagnosis system of claim 11, wherein said means 
for varying said grade value includes means for increasing 
said grade value by said point value of said diagnostic result 
of each said performed diagnostic step; and said means for 
adjusting said grade value includes means for reducing said 
grade value by said point value of said diagnostic result of 
each said previously performed diagnostic step that is deter- 
mined to be an invalid step. 

13. Hie diagnosis system of claim 9, wherein said means 
for performing a plurality of diagnostic steps is operable to 
perform diagnostic steps on a plurality of functional areas of 
said apparatus, each of said functional areas having a 
respective grade value representing a functional operative- 
ness of said respective functional area. 

14. The diagnosis system of claim 13, further comprising 
means for displaying said functional areas in order of 
decreasing grade values. 

15. The diagnosis system of claim 13, further comprising 
means for displaying said functional areas having respective 
grade values greater than a predetermined value. 

16. The diagnosis system of claim 13, further comprising 
means for designating said plurality of functional areas of 
said apparatus to be diagnosed. 

17. The diagnosis system of claim 13, further comprising 
storage means for storing said diagnostic steps to be per- 
formed to diagnose each of said functional areas of said 
apparatus; and wherein said means for performing further 
includes means for retrieving from said storage means said 
diagnostic steps to be performed. 

18. The diagnosis system of claim 17, wherein said 
apparatus is a data recording device; and said storage means 
stores diagnostic steps to be performed to diagnose each of 
said functional areas in a plurality of self diagnostic modes, 
said plurality of self diagnostic modes including an inde- 
pendent reel rotation diagnostic mode, an electric system 
calibration diagnostic mode, a mechanical calibration diag- 
nostic mode, and a data recording mode. 

19. The diagnosis system of claim 9, further comprising 
storage means for storing values representing point values 
for each possible diagnostic result of each of said diagnostic 
steps; and wherein said means for allocating a respective 
point value includes means for retrieving from said storage 
means a value corresponding to said respective result for 
said respective diagnostic step and means for assigning the 
retrieved value as said respective point value. 

20. A self diagnosis control apparatus which divides an 
apparatus under diagnosis into a plurality of areas under 
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diagnosis, each provided with an evaluation variable for 
performing a diagnosis in units of said areas under diagno- 
sis, comprising: 

(1) self diagnosis execution control means for executing 
the diagnosis based on diagnostic steps corresponding 
to said areas under diagnosis, at least some of said 
diagnostic steps corresponding to a plurality of said 
areas under diagnosis, said self diagnosis execution 
control means having a first storage means for storing 
said diagnostic steps corresponding to each of said 
areas under diagnosis from which specified diagnostic 
steps are read for execution and a storage means for 
storing information which tells whether any of said 
diagnostic steps has been executed; 

(2) execution result processing means for adding up 
points allotted to said evaluation variable based on an 
execution result of each diagnostic step, said execution 
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result processing means controlling detecting means 
for detecting whether there is any diagnostic step that 
is determined by another diagnostic step to be invalid 
based on its diagnostic result and said diagnosis execu- 
tion control means so that no diagnostic step deter- 
mined invalid based on a detection result, is to be 
executed, wherein, if an already executed diagnostic 
step is determined invalid based on said detection 
result, no point allotted by said invalid step is added to 
said evaluation variable; 

(3) display means for displaying a state of said apparatus 
under diagnosis based on a value of said evaluation 
variable for each of said areas; and 

(4) specification means for specifying said areas under 
diagnosis. 
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